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Traffic Telematics System 

Telematics is going to be a growth market for mobile communication; predictions for the next 
decade speak of over ten million customers. Manufacturers will be able to offer terminals at 
a reasonable price provided there are economical means of development and production 
Accordingly, mass production thereby creates the basis for high market penetration The 
world-w.de success of mobile communication like the GSM-Standard has proved that it is 
possible to penetrate the market quickly and to reach a great number of participants by co- 
ord.nat.ng specification commitees. With this joined document dealing with terminal specifi- 
ers ,t has become possib.e to create the appropriate framework for technical preparati- 
ons for the traffic telematics market including all partners (customer, service provider and 
equipment producer). 

An essential feature of the specification is the system's open architecture, because a mass 
market for a multitude of traffic telematic services both in the commercia! and the private 
sector can only be developed if open and standardized interface specifications are created. 

The mobilNy of traffic users is becoming more and more important as an economic factor 
intelligent and flexibie t,affic guidance systems are therefore necessary in order to maintain 
a smooth traffic flow whife the volume of traffic steadily increases. The aim is to introduce a, 
the earliest possible point a traffic telematics system which is both flexible and open to incor- 
porate future developments. This system should possess open standards interfaces 
thereby enabling the realization of a number of traffic management operations both in the 
commercia, and the private sector. „ can then support collective guidance and information 
services as well as personal ones. 

^~ 3Sed ° n m ° bi,e c — -ation, e.g. the digita. cellular mobile communicati- 
on standart GSM and navigation systems, e.g. the satellite navigation system GPS. the latter 
be,ng the dominant representative of the Global Navigation Satellite System (GNSS) The 
appl.cat.on of the concept is obviously not only restrictet to those particular communication 
and navgation systems, as any other kind of electromagnetic communication like even 
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microwave or infrared can be used. As welt any kind of navigation will fit in the concept of 
open standards like for example autonomous in-car navigation by use of sensors or any 
other kind of external and/or combined internal/external navigation systems like position de- 
termination by use of electromagnetic broadcasting means. In the following text GSM and 
GPS will be referred to as only one example of those various types of communication, espe- 
cially mobile radio, and navigation means, especially satellilte navigation, possible in this 
concept. 

GSM is already being used as an universal standard for language and data services in Eu- 
rope and beyond. GPS is a standardized procedure that is available word-wide. The high co- 
verage of the GSM networks means that the main investments in infrastructure have already 
been made, whereby the quick introduction of GSM based traffic telematics is guaranteed. It 
has to be stressed that the traffic telematics car terminals in particular can be used cross- 
border. The multi-functional design of these terminals forms the basis for a wide variety of 
offers and additional services for prospective customers. 

It is therefore an object of the present invention to provide a traffic telematics system with 
easily variable conception. According to one aspect of the present invention there is provided 
a traffic telematics system as proposed in claim 1. According to another aspect there is pro- 
vided a method for use in a traffic telematics system as proposed in claim 4. The traffic te- 
lematics system contains one or more subsystems. Each of the subsystems can be de- 
signed to fulfil special tasks within the whole system such as communication, location, ac- 
cess control, input/output. One possibility of arranging the subsystems is to build up a base 
system which the one or more subsytems are assigned to. The whole system can be run in 
the way that base functions are assigned to the base system and those functions are used to 
run and/or control subfunctions of one or more subsystems. It is proposed to design stan- 
dardized interfaces for the telematics system to facilitate communication and/or connection. 
One special example of a conception of such a base system, subsystems and interfaces will 
be shown below more expicitely. 

Object of Specification 

As shown in fig. 1, this specification focuses especially on the functional description of the 
terminal platform as the connecting link between terminal production and applications. With 
this concept it will be possible to transfer applications to different terminals, which is the ba- 
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sis for the availability of terminals on a mass market. Furthermore, existing services can be 
implemented into terminals by different manufacturers, hence making individual product de- 

sign possible. 

The traffic telematics terminal is a complete system which can be integrated into the vehicle. 
The traffic telematics base terminal that this document specifies is the terminal without the 
parts belonging to the applications. The terminal platform includes subsystems, which are 
necessary for many traffic telematics applications, as well as the cross-section Routing + 
System Control and priority management/With respect to the architecture of the base termi- 
nal introduced in chaper 1.2 this specification establishes the base functions for the steering 
and using of subsystems like communication, location, chipcardreader. and input/output. 

These base functions al.ow defined access to the subsystems while several applications are 
running at the same time, without one of these blocking the other. Additional external appli- 
cations can also use these subsystems via a standardized interface, the Standard Commu- 
nications Interface (SCI) and avoid a doubling of the GSM- or the GPS-module. 

The aim is to establish a standard for application sequences by addressing and using the 
base funct.ons. Possible applications of traffic telematics are described in [4], [5], [6] and [9]. 

Moreover, the specification of the base functions does not have to define the hardware of the 
mum-functional base terminal. Neither the CPU nor the operating system nor the bus structu- 
re are- being established, which is why the base functions will be incorporated into a multitu- 
de of .ntegrated or modular terminal realizations. Consequently, it is not necessary for com- 
panies developing applications and services to acquire a thorough technical knowledge 
about basic technologies and hardware construction. 

The efficient transfer of applications to different terminal realizations is only possible on the 
basis of a standardization of the base functions. 



Functional Architecture 

An important part of this specification is the setting up of the interface between applications 
and base functions, preferrab.y chosen as an extra interface, the Application Programming 
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Interface (API) (see fig. 2). It can nevertheless be useful in some cases to define only one 
common interface within the system. The base functions preferrably include the subsystems 
communication, location, access control, input/output as well as the Standard Communicati- 
ons Interface (SCI)). The connection between the applications and the subsystems is being 
established by the cross-section function Routing and System Control. While the Routing is 
confined to addressing tasks, the system control undertakes the monitoring of functions and 
the recording of failures and errors. 

With the help of the communication subsystem connections to the GSM network can be 
established by adding a GSM module. It has to be pointed out again that GSM as well as 
GPS are only examples of the already above mentioned means of communication and navi- 
gation which can be used in this concept. Data can be exchanged with central service units 
located in the landline network. Other networks can in principle be connected to the com- 
munication subsystem as well, provided the function commands are being adjusted. The 
GPS receiver supplies data from the satellite-based navigation system GPS. which allows 
the position determination of the vehicle. In contrast to the GSM card reader currently in use 
an additional chipcard reading device can be impolemented to perform the additional functi- 
on of processing a traffic telematics chipcard (see [8]), which can be a combination of GSM 
and traffic telematics chipcard. The chipcard's function is then primarily to support the traffic 
telematics applications [6]. The input/output unit supplies the user with information. He or 
she can moreover input information to control the base terminal. The SCI allows external 
periphery device access to as many functions of the base device as possible. 

Certain subsystems can be designed to incorporate a priority management, whereby top 
priority user requests can be dealt with immediately, that is to say it is possible to disrupt 
otheF functions, such as the use of the display or a GSM connection. 

The position determination of the vehicle can be supported with sensors (e.g. Dead Rek- 
koning). A more precise determination can be achieved by using differential information in 
the RTCM format. 

For the operation of the GSM module the system's own input/output unit can be connected 
directly. Provided it is compliant with ETSI GSM 07.07, this unit can also be used as an in- 
put/output unit for traffic telematics applications. 
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The API is connected with external devices via the Standard r nm ■ >■ 

fSClw^o fin \\ u *u c*r> standard Communications interface 

. sr.* vl " i^rnrr ^ te,emato — - - - 

. .h, m . Bus system ™ z he v^r :;r;: wi '' p r ipa,,y be opera,,n9 usin9 

Adaption) connected v,a an adaption (Car Bus 

A language service is . in edition to the GSM data services, an optiona, par, of the base de- 

The following description gives one defied exampie o, the present invention Calmed. 

2 Scope of Base Functions 

2.1 Summary of the Base Functions and Externa, mterfaces 

The common (unctions of the multi-functional base device are sur^ipr, , * . 

They have an interface .„ in. „ supplied as base functions. 

components s cra G^M GPS ; ^ * ^ "» ™ ~ h ~ 

ms sucn as GSM, GPS, chipcard reader, input/output devices »tn Th. k , . 
ons can be grouped together under the .Cowing headings: ' UnC "- 



GSM Communication: 



GPS Location: 



The base function for GSM communication plus the GSM modu- 
le constitute access to the GSM network. 

The base function for GPS location plus the GSM modu.e which 
contains the algorithm for position determination and identifica- 
tion constitute the location subsystem. 
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Other GNSS positioning systems can be implemented into this 
location subsystem besides the GPS position determination. 
Further location modules would be necessary for this. However, 
in the first instance the GPS module will be considered only. 
It is important to design the location subsystem in such a way 
that the service applications will not be affected if further locati- 
on procedures are added in the future. The GPS location can be 
supplemented with other procedures like GSM triggering via 
Underlay Broadcast Cell. The location subsystem remains un- 
changed, if the satellite navigation is supported by external sen- 
sors and differential information. Differential information can eit- 
her be fed directly into the location subsystem or they can be 
requested via the API (for external sources via the SCI) and 
then passed on the the location subsystem. 



Access Control: The subsystem "access control" contains the base functions for 

the chipcard handling 

Input/Output: This includes input/output functions for display and operating 

elements. 



Furthermore, general functions are being provided 

Routing + System Control The Routing organizes the flow of information from applications 

to base functions, from base functions to applications, between 
applications and between base functions. The System Control 
performs tasks such as initialization (configuration), status con- 
trol (error status), diagnosis, version administration and monito : 
ring individual processes (watchdog). 



Priority Management The priority management regulates access to the base functi- 

ons. 
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2.2 Functional Description 

2.2.1 Base Functions of the Subsystem Communication 

Many .raffic telematics applications have in common .he necessity ,or mobile communicati- 
on. The Global System fo, Mobile Communication (GSM, provides the basis for tne subsy- 
stem commincation to be used Europe-wide. The subsystem commincation has been de- 
s,gned ,n such a way that alternative networks can be added, thereby ieaving the system 
open for specie, mobile communication networks iike inmarsat. The functional architecture is 
transferable as long as the function commands are modified accordingly. 

,?™I?T,H° mminCa,i0n OHerS '° «^ -is, ,n exchange in- 

ZT „ Cemral Unl,) aea ' S W " h ,he C °~ -"*<»• ^ base 

CTt *" '° Ch °° Se ,he " aKeSS ,0 ' he GSM H ~ - su 9gest 

he use of AT commands (as laid down in the GSM recommendations 07.05 ( 2 , and 07 07 

1 »r 7 3 C ° mmunica,ions Table (CST,. which informs app.ica.ions 

about the availability of data services. w»v-auons 

^l^,n ri ,Un ? n h " indi^eC, ^ C ° mmand aCCSSS " a " 0WS a ~" S — <° «» GSM 

r rir n by usins certa,n at -~ ™- — * ~ <° ~ 8 

"° a " mana9Smenr • *»• —^nisms in case o, a wrong con- 

nec,,on, Th,s re,,eves .he ap P ,ica,ion o, .he .ask of dealing wi,h redia, and connecion errors 



In order to assist the use of the connection oriented Bearer Services with TASP4 (Telematic 
APP ca„o . Secunty Protocol, layer 4, an additional end-to-end protocol has been * tZ or 

on, I; ~ Si0n b ' r0m f BaSS **" ,0 "» — ' ^ -~ —cat, 
contains the following base functions: 

1. GSM data transfer 

2. indirect AT Command Access 

3. Communications Service Table 

4. Call Management 
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5. end-to-end protocoll 

Illustration 2.2.1-1 shows the functional architecture of the subsystem commincation 

Illustration 2-2.1-1: Functional Architecture of the subsystem commincation 

Certain data services for traffic telematics applications are recommended for use within the 
GSM network, these include Teleservice 21 (SMS-MT), Teleservice 22 (SMS-MO), Bearer 
Service 24 (2400 Bit/s) and Bearer Service 26 (9600 Bit/s), both transparent and non- 
transparent. Future services include Teleservice 23 (SMS Cell Broadcast) and GPRS 
(General Packet Radio Service) with. its variant PDSS. 

The available data services are dependant on country and network. The application selects 
the data service (e.g. SMS, BS24 or BS26) and is passed over as a parameter to the base 
function with the message. 

An application can choose between different data services when communicating with its 
center. The terminal application has to be informed via the center, which data service is to 
be preferred. 

Since there is no guarantee that the preferred data service is locally available, a Communi- 
cations Service Table (CST) is kept by the subsystem commincation. The table's purpose is 
to record the success (or lack of it) in trying to contact a certain service; it is therefore able to 
inform an application whether the requested GSM service is available without the application 
having to contact it. In case there are any doubts the trial and error method is being applied. 

The Communications Service Table also records which data services are supported by the 
base device. It can then inform the application which services are implemented and therefore 
preferable. 

The applications decide for themselves, whether they want to follow the table's suggestion or 
whether they prefer an alternative service. 
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The error handling mechanism is designed to deal with problems concerning the GSM con- 
nection handling. The TASP4 end-to-end protocol is implemented into the subsystem com- 
mincation. which, if the Bearer Services (transparent and non-transparent) are used, guaran- 
tees a save data transfer between base device and service center (see illustration 2.2.1.-2).. 

Illustralion 2.2.,-2 : Components of Communication between base terminal and center 

Besides using the GSM module /noVrecf/ywith the aid of basic function commands , there wil, 
also be direct access to the module. Traffic telematics applications wil, always gain access 
indirectly by using the appropriate base function commands. 

Applications for data transfer such as PC and FAX. afready in common use today, take di- 
rect access; they can be connected to the base device without altering the software. Direct 
access is only possible via the standard communication interface, which is why the SCI has 
to be able to recognize a request for direct access. Otherwise there would be a conflict if for 
exarnp^. a top priority traffic telematics appficatton (such as an emergency ca„) would be 
blocked by a FAX transmission. These conflicts wil, be solved by the cal, management 



2.2.1.1 GSM Data Transfer 
Addressing the Service Center 



be'r'nrTr Cen ' erS Ph ° ne nUmbe ' S Wi " 66 prwWed - " * is to 

be established, the application passes the number on to the appropriate service center „ is 
the application's responsibility to update the number i, necessary. 



Dialog Sequence 



Both the service center and the terminal application can star, a dialog. II. for example, there 
are messages to be send to a seivice center or information „ to be requested from the se- 
vice center, me terminal application starts a dialog. The dialog structure is more or ,ess the 
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same for all GSM data services, regardless of whether a Bearer Service, a Short Message 
Service, the future General Packet Radio Service or the Packet Data on Signalling Channels 
Service (PDS) is used. Illustration 2.2.1.-3 shows a dialog sequence for line oriented con- 
nection which has been initiated by an application in the terminal. While the dialog sequence 
in the base device is unchangeable, the service center sequence can be varied. 
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Illustration 2.2.1-3: GSM dialog sequence of a Bearer Services (connection oriented), initia- 
ted by the terminal application with an example sequence in the service 



center 



The individual requests and messages are described in chapter 3 (API specification) The 
term ..message" refers to both requests and messages. Strictly speaking, the commands 
descnbed are ..primitives", as defined by communication technology, as they regulate the 
communication sequence with the next level. However, since these are commands and se- 
quences which concern the relation between applications and base functions only, in this 
document the term ..messages" will be used throughout. 

Illustration 2.2.1-3 shows that the communication sequence consists of three phases. 

The first phase opens up a logical communication channel for the data transfer between the 
application and the subsystem commincation. The connection request contains further pa- 
rameters besides the number of the service center. Information regarding the preferable 
GSM data service and the Application Service Identifier (asi). for example, are important pa- 
rameters. There is a common European standard for every traffic telematics service If line 
onented connections are concerned, the setup of the physical connection via an aerial inter- 
face has to be confirmed by the center, before the base function can open a channel and 
allocate a channel number. Packet oriented services like SMS do not need a confirmation by 
the center. Since in the case of these services the SMS center supports a secure connecti- 
on, the TASP4 end-to-end protocol (which will be described later on) does not need to be 
used. The request to open a communication channel is immediatly followed by the confirma- 
tion by the base function and the allocation of a channel number. 

The second phase allows a two-way exchange of data (transmission and reception) Confir- 
mation of reception is handled differently by connection oriented services and packet orien- 
ted services. Because Bearer Services employ the end-tc-end protocol, this protocol con- 
f.rms the reception to the sender. As for the Short Message Service, the reception is confir- 
med by the SMS center without the message having been transferred to the traffic telematics 
center. 
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If a confirmation by the application becomes necessary because of the contents of the 
transferred data (e.g. payment security), the application has to incorporate this in its respon- 
se message. 

In the third phase the- existing communication channel is closed. Both the center and the ba- 
se device can clear the connection. As a rule the connection is cleared by the party that in- 
itiated the communication. There are exceptions to this rule, however, for example if an exi- 
sting connection is disrupted (priority management), if existing connections are used by se- 
veral traffic telematics applications at the same time, or if a connection is activated by the 
other party or the network (e.g. radio shadow). Moreover, if there is no data transfer during a 
defined period of time or if the connection exceeds the defined maximum length this will be 
recorded (Watchdog Function) and a disconnection will be initiated by the base function. If a 
request exists to close the channel in a packet orientated communication, only the logical 
channel between application and base function is being closed. The base function can there- 
fore confirm the request immediately. The same goes for connection oriented communica- 
ton: the confirmation of the closure of the logical channel between application and base 
function immediatly follows the connection cleardown. The end-to-end protocol informs the 
center about the cleardown and the center then confirms this. 

A dialog can also be started by a call from the center once it has passed the Call Manage- 
ment function (see chapter 2.2.1.4). In this case the mirror image of illustration 2.2.1-3 
applies; again the dialog sequence for the base device is regulated, the sequence for the 
center is an only an example. The base function, by using the Application Service Identifiers 
(asi), informs the application of an incoming call by sending the message 
„gsm_open_indication". The open command does not depend on any particular data service 
(Bearer Services or Short Message Service). In the second phase the data transfer remains 
unchanged; in the third phase the logical channel is closed. Is the end-to-end protocol in 
use, the base function sends the message „gsm_closeJnd" only if the end-to-end connecti- 
on is activated. In the case of the Short Message Service the call management initiates the 
M gsm_closr_ind u message; This happens either immediately after the transmission of the 
SMS packet or after a defined waiting period in case a follow-up message is expected. 



Priority Conflicts 
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Conflicting communication requirements are regulated within the subsystem by the priority 
management function. The priority of each new communication request is compared with 
running communications. If a transmission request with a higher priority is registered, the 
ex.st.ng physical connection will be disrupted and the application, whose communication has 
been disconnected, will be informed. However, the logical connection between application 
and base function (as well as the channel number) remain unaffected. Once the communi- 
cation of higher priority has been completed (connection request, data transfer, connection 
cleardown) the physical connection will be re-established and again a message will be send 
to the application (channel number). The communication will then be repeated. 

In case high priority data are to be send to the same center, the data transfer will be disrup- 
ted. The appl.cation whose communication was disrupted will be informed about this Both 
the logical channel and the physical connection with the center remain open. The high priori- 
ty data are then transferred; once this is completed the high priority channel is closed. At the 
same t.me the application, whose communication was disconnected, will be informed The 
end-to-end protocol will be re-implemented and the disrupted communication win be continu- 
ed. 

The base function establishes retrai. mechanisms which guarantee that a disrupted data 
transfer can be continued efficiently, .t makes sense to keep the connection open, if the sa- 
me service is going to be used. If. for example, a BS26 connection has been set up and the 
h.gh priority application will be transmitting via BS24. the existing connection can be used as 
long as it is supported by the application. Otherwise a connection cleardown and a new se- 
tup w.ll be necessary. The application concerned will be informed about the disconnection 



Multiple Use of an Existing Connection 



An ex.st.ng connection can by used by several applications at the same time, provided they 
al. use the same service and address the same service center. Within an existing connection 
several messages can be both transmitted and received by one application or by several 
applications in succession. 
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If a message is too long to be transmitted, it can be split into packets. However, all the pak- 
kets belonging to one message have to be send and the. correct transmission has to be con- 
firmed by the end-to-end protocol, before another message can be received or transmitted. 
There will be no facility for a complex transmission of several messages by the same or dif- 
ferent applications (muliplex operation). 

In order to end the communication the application sends a command to the base. function to 
close the channel. The logical communication channel between application and base functi- 
on will then be closed (as described under the heading ..Dialog Sequence"). If the same con- 
nection is still in use by other applications, the physical connection will only be cleared once 
these applications have completed their dialog with the service center. 



Watchdog Function 

The watchdog function monitors existing GSM connections. This function has the facility to 
disrupt connections if it detects system errors. Two timers have been implemented to per- 
form this. One timer determines the period of time after which a connection will be disrupted 
if the data flow stops. The other timer determines the maximum length of a connection. As 
soon as this length is exceeded the connection will be disrupted even if there are still data to 
be transmitted. 
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2-2,1.2 Indirect AT Command Access 



The .nd.rect AT Command Access allows applications to address the GSM module by using 
certa.n AT commands. Information regarding the status and initialization of the GSM modu.e 
can be requested this way. To gain access to the GSM modu.e it is recommended to use the 
extended AT commands, as described in the GSM Recommendations 07.05 [3] and 07 07 



[2] 



Most possibie AT commands are available via indirect access, except those that are needed 
for connection setup and dialog communication, because these functions are covered by by 
special base functions. 

AJist of available AT commands have been induded in appendix 2 o, this document (see 
chapter 5.2). 



2.2.1.3 Communications Service Table Access 

The application decides which data system i, wants to use. The subsystem communication 
nonetheiess provides a Communications Service Tabte (CST) in order to document the 
availability ol the services requested by the applications. 

The applications have access to the contents of this table via a function command and they 
can partly change the contents as we,,, e.g. to incorporate the phone number of a traffic te- 
lematics center (Calling Line Identity (CL,)). 

An application can enquire whether a certain communication service is implemented in the 
base errnina and whether the service is currently available. „ is therefore important tha, the 
has ,he facili, V t0 incl "1e both actual and potential services. 

We recommend to support the following communication services: 

Bearer services BS24. BS26 (transparent und non transparent) 
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Teleservices TS1 1 , TS21 , TS22, TS23 

plus Supplementary Services 

CLIP/CLIR and Call Wait are intended as Supplementary Services 



Initialization: 

The table is kept in a volatile changeable memory and each time the device is switched on, 
the table is updated in accordance with the GMS module. If the base terminal software is 
implemented or downloaded or if the terminal is upgraded, the services, supported by the 
base terminal, are entered in the CST. 



Updating: 

Data services available in the network are only updated if the GSM module is in operation. 
Every time a data transfer takes place or is rejected the status of the requested or employed 
data service is updated. The application receives information on whether the transfer took 
place or whether the data service was not available. The application then decides whether it 
wants to employ an alternative. 

Since the availability can change (e.g. because of network transfer or local failure) the table 
entries are valid for a limited period only. 



2.2.1.4 Call Management 

The Call Management performs two essential functions. Firstly, it checks incoming calls and 
determines whether they have been passed on by a traffic telematics center or whether ac- 
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72 wi^T' 7 " FAX aPp,iCa "°" iS '° ^ second,. ,he cal, managemen, 

deals with all kinds of communication errors. 

Examination of incoming Calls 

c A r„s 0 T7 h Cal ' r ^ 8ddre5Sed 6 " her '° ' raHta or ,o Cher appi, 

a c IT applica " ons ' FAX e,c - " ,he GSM modu,e ^ «•» ™° 

lden„,y CLI, and the canter is connected to the network either diredy or via ISDN the ser- 

127 ^ in, ° rmed °' nUmb6 '- Any ' U " her «<" - grated into data 
packe,s (so-called »in- b and-,n,orma„on T The appropriate CL, is pu, i„,„ the CST. 

For an y lnc lng ca|| „ has , o be dedaed me (o||owjng ^ ^ 

take piece and to whom the ca„ is addressed. What foilows is a demotion o, ,he procedure 

d ) Firs, o, a„ i, has to be determined whether the incoming cai, is a Short Message or no, ■: 

If it is not a SMS: 



(2) 



The cai, managemen, decides whe,her the Caliing Line ,den,it y is suppiied. In case the 

IH T 10 Ch6 ° k Whe,he ' " 66 aSS ' 9ned '° 3 ™«~cs 

f « does, he can ,s accepted. (Continue with (4). aNhough the examination o, the traf- 

Standard Communications Interlace (SCI). 

(3) in case the CL, is no, supplied the service is checked: I, i, is a FAX call the cal, 
- PU, through ,c the SCI. Otherwise the call is accepted (continue with ,4„ 

^ 7, ° "' n,0 ~ «*- - -se ,ne received in,orma,ion wil, 

el^ lL, 3 d ,ra " iC aPPliCa " 0n - * ~ " Wen„ f ica,ion 

exists, (he information will be passed on the the SCI. 



If it is a SMS: 



in case o, a received Short Message ,he procedure depends on which , e ,e service is used: 
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(A) In the case of TS 21 (SMS MT) the call management checks whether it can deduce the 
TT center from the originator number. If it can, the Short Message will be passed on to 
the appropriate applications. Otherwise the Short Messagewill be passed on to the 
SCI. 

(B) If it is not a TS21, the Short Message is treated as a TS23 (cell broadcast) and after 
evaluating the identifier it may be passed on to an application. 

Treatment of Communication Errors 

Access to the service center is not always possible. There are several explanations for this: 
the connection can be disturbed or disrupted or the center can be occupied. 

For that reason it is necessary to implement further individual correction mechanisms beside 
the GSM specific error treatment mechanism, such as cyclic retrials when setting up a con- 
nection. The redials are carried out in accordance with the GSM standard. Deviations are 
possible depending on the priority of the application. 

The CST keeps and manages information (redial meter with telephone number, time stamp 
and reason for refection) which the subsystem communication requires in order to keep to 
the restrictions for redials as laid down in the GSM recommendation 02.07. (Annex 
.Automatic calling repeat call attempt restrictions"). Excerpts of these restrictions are inclu- 
ded in appendix 1 . 

After a successful data transfer the application receives a confirmation. If there are any er- 
rors that cannot be rectified by the base function, the application will be informed about the 
causes. The application decides whether or not to pass information on to the user about the- 
se errors. 

Furthermore, the application can gain access to further error information via the network's 
Release Causes (e.g. Cause 63, i.e. the participant does not have a subscription for this 
service). The appropriate mechanisms for a call continuation and redialling device, on the 
other hand, are located in the base functions. 
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Appendix , provides a lis, of posslbie error messages (GSM 04.08. Table 10.86) which ,he 
base functions accept, condense and pass on to the applications. 

Once the connection has been estabiished. the procedure follows the end-to-end protocol 
described in the following chapter. protocol 



2.2.1.5 TASP4 end-to-end protocol 

The Transport Application Security Protocol presents end-to-end security and its tasks cor- 

nsT hetsT TT Pr0,0C °' °' ' eVe ' 4 " * mS "*- ^ - - .hell 

,u„,, J P " reqU ' red by ' ra,,IC ,el6ma,ics W**'™ I, performs .ewer 
functions than a classic transport protocol such as TCP. 

The TASP4 protocol is based on the LAPB protocol, wich can be found in the X25 



latedT 2 ; 2 Uil dla '° 9 SeqUenCS °' BSarer 8 "*- <~°" oriented, in- 

»,a.ed by a , errn , nal applica(ion ^ ^ ^ ^ ^ ^ ^ 

!irzr< > b 4 arr;. a communica,ton sequence - *■« ^ - 

n ZZT^ Z 1 " Sh ° WS aePendSnCieS "* *«« «*— 

.lner„hri cent BTO,0C °'- ^ d ' a '° 9 " qU "~ h »» base te ™ ina ' * de- 
>,ned wh,le ,ne center sequence is to be understood as an example. 



Scope of Functions: 

' SET TASP4 * 8 ™ d ' ,ted HDLC ~ » *~ ~ " - * 
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• Application: Only applications that work with a connection oriented transmission (Bearer 
Services) can employ the transport protocol TASP4. It cannot be used with the Short 
Message Service. 

• Multiplex: Multiplex (several users have access to the same TASP4 unit at the same 
time) is performed by a function located above the transport level. The TASP4 header 
does therefore not include any address information. 

• Connection Control: The connection control includes those elements of the protocol 
which deal with a secure establishment and termination fo the end-to-end connection. 

• Acknowledged information Transfer: The positive acknowlegement mechanism with 
time check guarantees that the packets reach the receiver securely. Packets that are not 
acknowledged will be sent again. 

• Unacknowledged Information Transfer: Unacknowledged Information Transfer via 
datagrams is employed by Broadcast and other simplified procedures. 

• Flow control: This is secured by the usual means (i.e. window, RNR). 

• Error control: CRC-1 6 is responsible for the protection of the data transfer. 

• Priority: Since there is only one user, no facility for priority handling has been implemen- 
ted at transport level. Priority handling is dealt with on the application level, for example 
by terminating one connection (DISC) in order to establish another of higher priority 
(SABM). 

• Line Oriented Transmission Links: Transfer via line oriented transmission links is ma- 
de possible by packet assembly (Begin-Flag + Length Indicator). 

• Transparence: Byte limits have to be adhered to; however, it is not recommended to 
cram bits, but to achieve transparence with the help of a length indicator. 

• Segmentation: Long messages can be split up into several segments, transmitted sepa- 
rately and put together again by the receiver. The maximum length of one segment is de- 
pendant on the Bearer Service. 

• Message Order: We assume-that the order of the messages will not be changed during 
transmission. This applies to both line oriented transmission (BS24) and connection orien- 
ted transmission via X.25 [7]. 

The message sequence and the Service Primitives of the TASP4 protocol are described in 
appendix 3. 
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2.2.2 Base Functions in the Subsystem Location 

One. common feature of many traffic telematics applications is the necessity to locate the 
veh,c.e. The Global Positioning System (GPS) forms the technical basis for the subsystem 
location. However, the subsystem has been designed in a way that allows the use of other 
locat.cn procedures. This means that if other location systems will be developed in the futu- 
re, they can be implemented into the system. The functional architecture of the system is 
transferable on the condition that modified function commands are added All the base 
functions of the subsystem location are based on a continuous position determination by the 
GPS receiver. 

In particular, the subsystem location contains the following base functions: 

1. Base Function GPS Base Data 

2. Base Function Geometry 

3. Base Function Approximation 

4. Base Function Waylength 

5. Base Function Waypoint 

The following illustration 2.2.2-1 shows the functional architecture ol the subsystem location 



Illustration 2.2.2-1 : Functional Architekture of the Subsystems Location 

The base functions described ,n this par. form two groups: call and response. In case o, the 
.wo .uncons GPS base dam and geometry the result follows .he application's request im- 
med,atly.The base function approximation runs in the background in case the GPS modute 
does not provide GPS positions ,e.g. because o, signal failure or re.,ec„on, and ,he position 
has to be approxrma.ed. Other base functions can ,e, opera.ions run in the background when 
asked to do so. The results will be sen, ,o the application the, made the request a, a later 
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The subsystem location does not process the priority information contained in the message's 
superframe (see chapter 3.2.1). Since the base functions GPS base data and geometry 
provide immediate results, an interruption would not make sense. Other base functions that 
run in the background do not use the GPS receiver exclusively, which means that a parallel 
processing does not cause any problems. 

The localization can be supported by sensors (such as Dead Reckoning, reading of the 
speedometer, acceleration sensors). With Dead Reckoning the position can be determined 
even if there is a temporary failure of the GPS module. The availability of the location sub- 
system is thereby increased. 

The precision of the position determination can be increased by using differential informati- 
on. Differential information can be passed on in two ways: either directly to the GPS module 
(provided that is technically feasable) or via the API (SCI for external sources). If an applica- 
tion needs DGPS corrected position data, it can request differential information from the 
center via the subsystem communication. Correction data, coming from the center will be 
forwarded to the subsystem location with an appropriate message. 

Since the system's processing power is limited, it is important to create an intelligent resour- 
ce control system.. However, this is not the subject of this specification. 



2.2.2.1 Base Function GPS Base Data 

The base function GPS base data is located right beside the interface to the GPS module. It 
supplies both TT applications and GPS base functions with GPS position data. 

The bast \ jnction GPS base data processes GPS data sets - which are supplied in different 
formats depending on the GPS module - and translates them into a standard data set. 

On request, applications have the following data elements at their disposal: 

- date and time (UTC) 

- geographical latitude 
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- geographical longitude 

- altitude (Measured Sea Level) 

- Horizontal Dilution of Precision (HDOP) 

- Estimated Position Error south-north direction (EPE(x)) 

- Estimated Position Error west-east direction (EPE(y)) 

- horizontal speed value 

- heading 

- number of satellites (those that can be used theoretically and those that are 
actually used) 

- parameter necessary to note a change of constellation of the relevant satellites 

- Type of Position (TOP) 

- receiver specific data 

- Pseudorange Data und Pseudorange Rate 

There are always more data elements than an application actually needs. Each application 
chooses the elements it needs with the help of a bitmap and then puts in a request for these 
elements only, .f several TT applications request different data elements, the whole set of 
data will be send to the application. A bitmap indicates which data the set contains. 

Date and time of each measure point are determined directly by the GPS receiver's internal 
dial. Once every four years applications will have to pay attention to the leap second since at 
that point two consecutive data sets will have the same time stamp. 

Geographical longitude and latitude (referring to WGS 84) of the measure point are key pa- 
rameter for the position determination. 

The DOP value is the ratio between the error of the receiver position and the error of the 
satellite position. It allows conclusions about the geometric constellation of satellites and the- 
refore about the precision of the actual position. Of the different DOP values only the Hori- 
zontal Dilution of Precision (HDOP) wi.l be provided, since only this value is relevant for po- 

sition determination in the plain. 

The Estimated Position Error is a statistical 1-sigma-value of a gaussian distribution and in- 
dicates the estimated horizontal position error, using the metrical system. It consists of two 
values, the position error in south-north direction (EPE(x)) and the position error in west-east 
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direction (EPE(y)). If a receiver can only determine one EPE value, the two position errors 
are identical. 

Speed is here defined as the horizontal speed value. The heading is the angle (in degrees) 
of the horizontal speed vector in northern direction (i.e. 0 degree reads ..north"). The rotation 
goes clockwise. If the speed falls below a certain value (minimum speed), the speed is re- 
corded as 0 m/s and the heading will appear as ..invalid". The minimum speed is dependent 
on the type of GPS module and the existence of support sensors. 

The parameters to indicate a change in satellite constellation has either the value 0 („no 
change of constellation") or 1 (..change of constellation"). This parameter serves as an indi- 
cator for a change in position. 

Pseudorange data contain information regarding the signal propagation time of individual 
satellites; with these data the differential GPS position can be calculated in retrospect. 
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The Type of Position (TOP) 



describes how the pos«ion is ,o be determined. The TOP is a bitmap and contains the fo.- 

lowing flags: 

- invalid position (no current position determination necessary) 

- three-dimensional autonomous position 

- two-dimensional autonomous position 

- three-dimensional differential position 

- two-dimensional differential position 

- two-dimensional position calculation with fixed height 

- position generated by forward approximation 

- position generated by backward approximation 

- position calculated with sensor support 

I. the base .unction GPS base data is supplied with an invaiid position from the GPS receiver 
£nc .current posKion determination is possibie, the base function approximation caicuiates 

LZ^tZ 1351 " Va " d P0Si "° nS - 2) Wteh ha ™ «° be *>r this 

purpose. The mmtmum requirement is a linear approximation (i.e. n . 2). 

a AS ba S 2aT a " d P ° S " i0nS " aVai,ab ' e a ° aln ^ ^ W™on wil, carry ou, 

^rztTr' ,n order ,o " ,he 9ap - These da,a - * » - - 

Bo,h forward and backward approximated positions are indicated in the TOP bitmap. 

The two-dimensional position calculation can be carried out in two ways Firstlv if ,h» 
no suites available a, any particular moment the GPS receiver "Z,^ 

minatln " aad '" 0nal in ' 0rma,i0n ,0 ™ ' he ""^ °< - P"*on dete, 

>a«ude o. «. current posttion. The application sends the altitude to the base function GPS 
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base data together with the radius of the circle surrounding its current position within which 
the defined altitude is still correct. The base function GPS base data checks whether the 
next position is still within that circle by analyzing the current speed and time step. Only if 
that is the case the application will pass on the altitude to the GPS receiver. This procedure 
is repeated with each new position. If the analysis reveals that the next position will be outsi- 
de the circle, the established altitude will be deleted either by the base function or, using an 
appropriate message, by the application. Any conflicts in altitudes between different applica- 
tions is to be solved within the base terminal. This can even lead to a situation where none of 
the altitudes can be used. 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



2> 

2.2.2.2 Base Function Geometry 

The base (unction geometry contains mathematica, basic functions which are put at the dis- 
posal o, both Cher base functions and traffic teiematics appiication, The emulations are 
earned out in accordance with WGS 84. 

The following mathematical functions have been implemented: 

- calculation of radial distance between two positions 

- calculation of longitudinal distance between two positions 

- calculation of latitudinal distance between two positions 

- Nation of direction angle of one position against another 
The function call can take two forms: 

- L a Lltn ! hT" an9 ' e °' *"° POSi,i ° nS Wh ' Ch *** the caf, 
^cu.a„o„ o. d,stanc e and an 9 ,e of the current position in refation to another position 
which ts determined during the call 

IT T T' a "° nS * * reC ° mmended <° — approximation formulas for smal, distances 
and angles which are less exact but save time in calculation. 

2.2.2.3 Base Function Approximation 

pT n r;rrr tion v sed in those situations where there are - ^ ™ 

va uts pee a d d ! ^ ***** " °" ** *** ° f 

values speed and d.rect.on movement can be calculated for each aproximated position. 

There are two different approximation procedures: 
forward approximation in real time and 
backward approximation. 
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The forward approximation in real time is carried out automatically and the approximated 
position is forwarded to the base function GPS base data. All TT applications that have re- 
quested GPS positions will be supplied with the forward approximated position without an 
extra request. Backward approximated positions, on the other hand, are supplied to .applica- 
tions on explicit request only. 

As a minimum requirement the base function approximation has to be able to carry out a li- 
near approximation. This can be done by using the polynomial procedure, described below, 
by assuming the degree of the polynom to be 1 . The polynomial approximation is to be un- 
derstood as a suggestion for an improved approximation procedure. However, other proce- 
dures can be implemented by the manufacturer. 

If the base function GPS base data receives an invalid set of data, the base function 
approximation provides an estimated position. 

First of all a forward approximation is carried through and the calculated positions are pas- 
sed back to the base function GPS base data. The base function can only produce a limited 
number of forward approximated posititons. A maximum number has to be determined; once 
this maximum has been exceeded invalid data will be supplied. 

The Estimated Position Error (EPE) will be calculated for each position (that goes for 
approximated positions as well). In the case of forward approximations the EPE value rises 
with each approximation. 

Once the first valid position is supplied after a number of invalid positions a backward 
approximation will be carried out in order to fill the gap in vehicle positions. In case an appli- 
cation recognizes the first valid position by its TOP, it has to request the backward approxi- 
mated positions from the base function approximation, if it requires these data. 

Backward approximations will only be carried out, if the amount of time where no valid posi- 
tions have been produced does not exceed a certain defined limit. 

If the subsystem location is supported by sensors, which in case of failure of the GPS modu- 
le can carry on supplying continuous positions for a certain amount of time, forward and 
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backward approximations wil, no. be used during that time. Approximation rouines will only 
be employed after the sensor position determination has been discontinued. 

The following suggestion for an improved polynomial approximation procedure uses po- 
lynom, a , unctlons 0( the same degree ^ ^ ^ ^ > 

r!Z ,UnC,i ° n ^ USed " 3 Parame ' er and - * >° ~ For a 
porynom, a , approximation o, the degree m, <m + 1, positions before the gap have to be 

ne the degree of the polynom on a scale between 1 and 5. 



a) Forward Approximation in Real Time 

After a signal failure a forward approximation of positions following the movement of the ve- 
hide will be carried through (see illustration 2.2.2-2). 

,™TT T^'™" 0 " Wi " bS Carried ° ut ^ * P°'Vnomia, function with the degree m 
■n order to sotve the resutiing equation the la.es, ,m + 1, valid positions have to be avaLle 

Is a'n ™? TT C °° rdina ' e X <* *** h ai '~«°"> « — 

i" zizr 9ous procedure can be ap * d ,or ,he — v , 

The latest (m+1 ) valid positions („old positions") are: 

*o=*(' 0 ) position at point in time 
x . = ) position at point in time t x 

x «> = ) position at point in time t m 

The GPS receiver wi„ be adjusted to a defined period of time and thereby regu.ates the cap 
between the individual points. y"'<*ies me gap 
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Illustration 2.2.2-2: Polynomial Forward Approximation 



In case of a signal failure of the GPS receiver the first approximated position a,., at a point in 
time r_ ; can be calculated by using the polynomial formulation: 



x = a u + cu + a 2 r 2 + a 1 r 1 +...+a m r" 
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The coefficients a 0 ,a,,a 3 a m are calculated using the old positions: 



fx > 














= A- 











mix A = 



1 'o 'o 

\ t, tf 



, 1 / ' t 1 t m 
\ m 'm *" ••• t m J 



0 

a, 



Ay 



The forward approximated positions A m+I ,* m+2 . at different points in time 
'«.+!• 'm+2' / «+3.-- are determined by using the formulation: 



mit i = m +l,m + 2,m+3,... 



b) Backward Approximation 



A backward approximation will be carried through after a signal failure once the first valid 
position after the gap becomes available (see illustration 2.2.2-3.). The backward approxi- 
mation is based on the same procedure as the forward approximation. 
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The backward approximation is carried out with the help of a polynomial function of the same 
degree. To solve the resulting equations both the latest m valid positions before the gap („old 
positions") and the first valid position („new postition") after the gap have to be available. The 
approximation procedure is the same with forward and backward approximation. 

The following equations are established for the latitudinal coordinate x (x axis in north di- 
rection). The procedure is analoguous for the longitudinal coordinate y (y axis in east directi- 
on). 

If the number of missing positions is nhole, the latest m valid positions before the gap („old 
positions") and the first new valid position after the gap („new position") are: 

= *( ; o) °ld position at point in time /, : 
x x = x(t y ) old position at point in time / ( 

x m _ t = x(r m ^) old position at point in time t m _ % 
x m ^ r = x(r mrmholr ) new position at point in time t m ^. 

The amount of time to elapse between these points (normally around one second) is deter- 
mined and the GPS receiver is adjusted accordingly. The first valid position after the gap 
x m+nhoh IS situated exactly (nhole + \) time segments after the last position before the gap 



Illustration 2.2.2-3: Polynomial Backward Approximation 



The first backward approximatied position of the gap .v. can be calculated by using the po- 
lynomial formulation: 

x = q +fl/ + fl,/ 3 +fl l /'+...+fl/ 1 
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The coefficients a Q ,a l9 a 2 ,,„ 9 a m are calculated using the valid positions: 



mit A — 



fx ■> 
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a \ 








\ X manhole J 








'o' 
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^ m+nhttttr 
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m+nholv / 



a, 



= (A T •Ay , .A T 



\ X m+nhole J 



By completing the following formulation all backward approximated positions of the gap 
.* m+2 at the points in time t m j m+] , r m+2 t m , nhoU _ ( can be determined: 



x, = a„ +a t t, +a 2 t t 2 + flj r, 3 +...+a m r," 



mit i = m,m+\,...,m + nhoie-i 



2.2.2.4 Base Function Wayiength 

The base function wayiength contains functions which are- similar to the milage indicator of 
the vehicle. It requests GPS data sets from the base function GPS base data and employs 
the base function geometry for the calculation of distances. 

Distances between positions are calculated by using the longitudinal and latitudinal coordi- 
nates of the measure points. The wayiength is the sum of the distances between individual 
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positions (aerial connection). The base function includes both variations of the waylength: in- 
crementation and decrementation. 

Incrementation means that the waylength meter is adjusted to zero before the start. With 
each new position the distance to the preceding position (aerial connection) is calculated and 
then added. If a certain mark has been determined by the application, the application will be 
informed once that mark has been passed. In addition to this, the application can request a 
meter reading at any time. 

In the case of incrementation the applicaion can terminate the meter if it is not required any 
longer. Only then can the meter be started anew. If the meter has not been terminated, the 
base function will deactivate the meter as soon as it passes a certain maximum reading. 

The decrementation is being realised as an incrementation with negative values. In this case 
the application determines the waylength to be covered as a negative value. With each new 
position the distance to the preceding position is added to this negative value. Once the 
meter passes the mark „0 meter", i.e. the vehicle has covered the defined waylength, a mes- 
sage will be send. An application can define certain marks as negative values, in which case 
it will be informed once that mark has been exceeded. In addition, the application can ex- 
plicitly request a waylength meter reading at any time. 

For example, an application requests a message when a waylength of 2000 m has been 
covered. Additional messages are to be sent when 200 m, 100 m and 50 m are left to be 
covered. For that purpose the application has to determine the overall waylength of -2000 m 
as well as meter marks at -200 m, -100 m and -50 m. The base function will then inform the 
application of a meter reading at -200 m, -100 m, -50 m, and 0 m („waylength covered"). 

The waylength meter will be terminated automatically by the base function once the mark „0 
meter" is passed. The meter can be terminated before that point, if the application does not 
require any further information. The application can terminate each meter individually or all 
meters at once. 

In case of a failure of GPS data the current meter reading will be calculated with the help of 
the backward calculated positions during the time of failure. If during the signal failure one or 
more of the marks have been exceeded, the application will receive a message with the ac- 
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tua, mete, reading, if.*. who,e waylength has been covered during ^ ^ ^ ^ _ 
when ca,cu,a,ing ,he waylength using the positions during the failure - will continue to incre- 
ment after exceeding the ma, k .0 meter untii the current meter reading (e.g. ...200m" for 
whole wayiength pius additional 200m covered-,. The base function wil, inform the applica- 
tion of this meter reading and then terminate the meter. - 

Each appiication can initiate several wayiength meters a, the same time. ,0 which it has to 
ailoca e iog.cai IDs. ine case function wayiength wif, be able ,0 recognize, which meter be- 

longs to which application. 

in addition ,0 the waylength meters which can be initialed and terminated by an application. 

a globa waylength meter win be established that increments in segments o, one meter each 

Th, „, be ,n,„a,ized when the base terminal is put in operation with a value se, a, 0 meter 

and ,. w,„ rema,n active during the entire time o, operation. „ the terminal is switched off and 
sw^hed on again , , ne meter rema . ns same Ne|(her teminai ^ 

app„ca„ons can stop or pu, back this wayfer^th meter. The applications can expUCly re- 
quest a current meter reading of the global waylength meter. 



2.2.2.5 Base Function Waypoint 

LTnuhll TT waypolnt Ga,cu ' mes ,he dis,ance be,ween ,he vehic,e «* a -y- 
Z2 TJ7 ed by an appllcauon - Eaoh waypoim * an — ^ * **• - 

.ens,on crcle or rectangle). The size of the waycoin, can be one meter or several hundreds 

p"L\~r R b , e ' n ; 0m,ed Whe " ~*" °' *«- «* -ea and when i,' 

passes the CENTER „ne (normal to preferred direction through the center of the waypoint). 

L h s?d a a7a T 0 " WayP °' nl d3,a Pr0VWed * *• GPS 

oTgeomet'J ^ Ca ' CU ' a "° nS ™ ™™ «* * "*» <»* >— 

The firs, variant of the waypoint, which the traffic telematics application determines is de 
ne y seeing . center point and a radius. The second variant is a rectangle, whlh . 
fned by the appl,ca„o„ by setting the center point as we,, as length and width. The crcle or 
rectangle wil, be framed by a hysteresis area ,0 proven, insignifican, changes in plsln 
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(e.g. drift loops) from releasing a message. The hysteresis area will be determined by the 
application. 

Moreover, the application defines a preferred direction and an aperture angle. Applications 
that do not want to determine a preferred direction can set the aperture angle at 360 degree. 
If the waypoint is defined as a rectangle, the rectangle's longitudinal axis will be put in align- 
ment with the preferred direction (see illustration 2.2.2-4 and illustration 2.2.2-5). 

Illustration 2.2.2-4: Waypoint Geometry in Case of a Circle 

Illustration 2.2.2-5: Waypoint Geometry in Case of a Rectangle 

For each actual position the base function calculates the distance to the center of the way- 
point and compares this with the extension of the waypoint. 

If the vehicle arrives at the inner area, the message „status IN" will be sent (see illustration 
2.2.2-6 and illustration 2.2.2-7). In case a position momentarily changes to the hysteresis 
area (i.e. as a result of drift loops) and then back to the inner area, no message ..status IN" 
will be sent. 

If the vehicle crosses the CENTER line (normal to preferred direction through the center), 
the message „status CENTER" will be produced (see illustration 2.2.2-6 and illustration 
2.2.2-7). In addition, the application will be informed whether or not the heading of the ve- 
hicle remains within the aperture cone of the preferred direction. The current heading will 
appear as well. 

If a vehicle leaves the hysteresis area, the message „status OUT" will be released (see illu- 
stration 2.2.2-6 and illustration 2.2.2-7). In case the waypoint is deactivated by the applicati- 
on sending an appropriate message, the waypoint still remains activ. i.e. if the vehicle arrives 
at the waypoint again, the procedure described above will be repeated. 

The waypoint observation will be carried out both in case of valid positions and approximated 
positions (forward and backward). The application will be informed - when arriving at (IN 
message), crossing (CENTER message) and leaving (OUT message) a waypoint - on which 
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type of GPS positions (TOP value TOP (x), TOP (y)) the calculation is based. In particular 
the application will find out whether the calculation is based on actually measured or 
approximated positions. 

If the vehicle arrives at a waypoint and/or crosses the CENTER line and/or leaves the way- 
point, theapplication will be informed of this later by means of an appropriate message. 

All three messages ( .,.N". ..CENTER" and „OUT») will also tel. the application the time stamp 
of the GPS position that triggered the message as well as the distance of the position to the 
CENTER line. This puts the messages into a temporal and spacial context, which is of par- 
t.cular .mportance in the case of forward and backward approximated positions. If a situation 
occurs, where during the be.ated waypoint calculation with backward approximated positions 
the messages ...N" and „C ENTER" or JN". „C ENTER" and ..OUT" are reported simultaneous- 
ly, further information will be provided, i.e. the TOP value, the linear approximated point in 
t.me. the heading and the distance of the GPS position that triggered the CENTER message 
to the CENTER line. 

There will be no message if the vehicle crosses the hysteresis area only. 



Illustration 2.2.2-6: Example of vehicle crossing a circle: 

Point 1 : Vehicle arrives at inner area, message ..status IN" 

Point 2: Vehicle crosses the normal to preferred direction, message ..status 

center and ..heading within aperture cone of preferred direction" 
Point 3 : Vehicle leaves hysteresis area, message ..status OUT" 



Illustration 2.2.2-7: Example of vehicle crossing a rectangle: 

Point 1 : Vehicle arrives at inner area, message ..status IN" 

Point 2: Vehicle crosses the normal to preferred direction, message ..status 

center and ..heading within aperture cone of preferred direction" 
Point 3: Vehicle leaves hysteresis area, message ..status OUT" 

The IN message is produced when a waypoint is activated and the current GPS position in- 
dicates that the vehicle is located within the waypoint. 
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Each application can determine several waypoints (to which it has to allocate logical IDs) 
which can be processed simultaneously by the base function. The base function recognizes 
which waypoint belongs to which application. The application can deactivate each waypoint 
individually or all waypoints at once. 

An application is able to set up waypoints which are activated automatically, even after the 
system is switched off and initialized again. This can be useful for a potential application 
..recording traffic data". 
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2.2.3 Base Functions of the Subsystem Access Control 

The TT chipcard performs several important tasks to guarantee the smooth operation of the 
the traffic telematics system as a whole, These tasks include releasing new traffic telematics 
services, checking the authenticity of a participant, securing the communication path betwe- 
en base terminal and center and tolling via a local electronic purse. 

The subsystem access control (Chipcard Interface Module (CIM)) can be addressed by the 
applications by means of the following base functions: 

1 . Opening of a chipcard application 

2. Transparent command and data transfer 

3. Closing of a chipcard application 

The base functions do not include additional functions such as activating and deactivating 
the chipcard. 

The base functions listed above allow a communication between the applications situated in 
the terminal and the Chipcard Interface Module (CIM), without the applications having to 
know the chipcard's operating system. It follows that on the one hand different applications 
can use their own. specially developed chipcard. On the other hand it is possible to employ a 
multi-functional IntraGSM chipcard that allows access to numerous traffic telematics applica- 
tions. 

The Chipcard Interface Module can in principle be employed by several applications at the 
same time. 



2.2.3.1 Opening of a Chipcard Application 

In order to open a chipcard application in the CIM this base function needs an application 
identifier (aid). If this chipcard application has already been opened or if no such application 
ex.sts. an error message will be produced. This also happens if the chipcard has not been 
plugged in. 
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2.2.3.2 Closing of a Chipcard Application 

With the help of this base function a chipcard application can be closed. Executing this 
function has the same effect as resetting the card, i.e. all access conditions in use (e.g. 
..external authentication is carried out") will be moved back. In addition, the application of 
the CIM is no longer managed. 

2.2.3.3 Transparent Command and Data Transfer 

By means of this base function chipcard commands (depending on the chipcard's operating 
system) and data are transferred transparently to the chipcard via the Chipcard Interface 
Module and requested data are read off the chipcard and are passed on to the application, 
i.e. the CIM works as a protocol browser only. 

Unexpected occurances such as removing the chipcard during an application are indicated 
by status messages. Information on the status of the CIM can be requested at any time 
(even if no chipcard application is in use). 
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2.2.4 Base Functions of the Subsystem Input/Output 

input/output functions are required to operate the base terminal. These are necessary both 
in order to gain access to the traffic telematics applications and for the administration of the 
base terminal. It is recommended that the number of input/output units are kept to a mini- 
mum. Moreover, it has to be possible to implement additional input/output devices, depen- 
ding on the requirements of the individual applications. Such external input/output devices 
can be connected via the SCI and can be employed by both internal and external applicati- 
ons. 

Furthermore, it is desirable that already existing input/output units inside the vehicle can be 
employed as well. For example, it will be possible to use a radio supported by RDS or any 
other vehicle specific solutions as an input/output device. These devices will be controlled via 
the SCI, too, by means of API function commands. The available input/output devices have 
to comply with the requirements of the application regarding functionality, ergonomics and 
suitability for use, in order to guarantee a smooth running of the application. 

Individual components of the base terminal may already possess a possibility for input and 
output, e.g. a GSM mobile phone may be implemented in the terminal. It is desirable to use 
these modules as an input/output unit. Obviously, because of the physical actuality of the 
device, the place where it was installed, and user ergonomics, there will be restrictions on 
the operation. 

Technical data will have to be provided so that the different applications can gain access to 
the several input/output units. That is why input/output functions are combined in the base 
functions and are made available to the applications via the API. Internal and external traffic 
telemat.cs applications can therefore employ both input/output units integrated in the termi- 
nal and external ones as well. 

The user will have two functions at his or her disposal: on the one hand the output function 
wh.ch allows the presentation of information on a display unit (screen, light, loudspeaker) 
and on the other hand the input function, which support the entry of data via an input unit 
(keyboard, arrow keys, control button). An interpreter intervenes in order to guarantee a uni- 
f.ed address of the unit even if some of the input/output units are more convenient 



than 
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others. The architecture of the subsystem input/output, consisting of input/output unit and 
interpreter, is shown in illustration 2.2.4-1 . 

Illustration 2.2.4-1 : bock switching illustration of the subsystem input/output with interpreter 

Illustration 2.2.4-2: Possible realization of input/output unit 

As shown in illustration 2.2.4-2, the inputfoutput unit can consist of different display ele- 
ments, loudspeakers etc., all of which are accessible by using API commands. 

One or more input/output units can be controlled by the base functions or by the applications 
either directly or via the SCI. 

The functional architecture of the input/output subsystem is shown in illustration 2.2.4-2. 

Illustration 2.2.4-3: Functional architecture of the subsystem input/output 

There are two base functions incorporated in the subsystem input/output („display informati- 
on" and ^receive input")- These can be used to gain access to the input/output device (see 
illustration 2.2.4-3). 

2.2.4.1 Base Function ^Display Information" 

Each traffic telematics application has different requirements regarding the presentation of 
information. These includes the presentation of graphics, text and symbols, sometimes in 
connection with acoustic signals and information. Depending on the applications' require- 
ments, it has to be possible to use output devices in the form of simple line displays, gra- 
phics displays and displays of external equipment (such as radio supported by RDS, meters 
etc.). A universal solution is therefore required to allow the presentation of information by 
means of different kinds of displays. For this purpose a set of different types of information 
will be defined. If an information is to be displayed, the interpreter will be informed of the type 
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.oitTr an t ,he aa,a ,hat have ,o be ™ a The «»" *<*» 

format will be used to display the information. 

oTsXi' d 'r a, r r be ,mea * s,rinss in — ' »• — «> 

has o b T Cann °' ^ C ° n5idered 31 " me ' he is °^ developed. 

. has to be taKen ,n,o acocun, that as a minium requirement a line disp,ay I eigh, ,Ls 

(e.g. radio supported by RDS) has to be implemented. The string to be presented has " 

consis, of a forma, o, „, characters for the static display. A header w„l be placed be o 

stnng, which can be used by the application to inlorm the input/output unit o, „s formatting 

rrz% A „:r ,he m,erpre,er ° f ,he disp,ay - decide °- - — - ~ 

Lie, on 7' , ~" talio " 01 *>"«* ^ings the interpreter provides a running ,ex, 
fundon . ,h,s toon has to be supported by the display (.soft scrotling-). 

"ansfer mtt" T * ^ in, ° rma,i0n °" *» <" "» in ~"< "* » «■ 

^ !l 7 ^ '° 6 SUbSyS ' em inPU, ' 0U,PU, ' TW ° " mere 66 3dded '° 

z <. d U tr T" ,or how ,oh9 me in,orma,i ° n b swosed » ap ^ - *• *- 

Pfcy (. dur), the second t,mer determines the maximum amount o, time after which the dis- 
play of information has to take place (Lqueue). 

rZabC 7TT con,irms ,he reception °' ,he messa9e - " ,he «*— « 

s available and * the information can be displayed for a certain time . dur, the subsystem 
input/output will confirm the completion of the display , equest. " " subsystem 

SZ^r**"? <e ' S - '"'—a' ^ipmen, and user 

^ ^1^ as7 1 * RDS ' S US6d aS " ""<" <**«> have access to the 

priolTa e ih re 0 ,0 *" '° ^ Variabte 

cZ 7,0 he ;7 S T 9nea '° ~ ' yPeS °' ir '° rmati0n ' WNch Ca " cha "9° «" 
cording to the current display status. 

An information o, low priority cannot interrupt a dispiay of a higher priority. ,„ this case the 
^ priority information waits in the queue. „ the dispiay becomes availabl during m " * 
mum amount o, time L queue allowed .or the display of the low priority informal the in 
fo mation w , be displayed; otherwise the information w,„ be rejected and an app'r p J te 
message w„ be sen, ,o ,he applica.ion. The application then decides whether „ wa Z l 
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new its request to display the information. In this case the application has to store the most 
recent information it wants to display. . 

An information of high priority can interrupt a current display with a lower priority and will be 
displayed immediatly. The low priority information again waits in the queue. Once the display 
of the high priority information is completed, the interrupted information will be restored, pro- 
vided the maximum amount of time t__queue allowed for the display of the low priority infor- 
mation has not been surpassed. Otherwise the interrupted display will not be restored and 
the application will be informed of this. Again the application can renew its request to display 
the information if it decides to do so. 

If a display is to be interrupted, it still has to make sure that the information appears for a 
certain minimum amount of time. The precise sequence of events is described in chapter 
3.2.6. below. 



2.2.4.2 Base Function „ Receive Input" 

The input function, too, can be used universally with the help of an interpreter, because diffe- 
ren variants of operating elements have been implemented. As in the case of the display 
medium a distinction has to be made between input devices that fulfill the minimum require- 
ments and those that provide optimum support for complex applications. The minimum re- 
quirements for an interactive operation of the input/output unit, where at the very least num- 
bers and letters can be entered, will have to be specified at a later point. 

Input devices are necessary for two reasons. Firstly, applications need inputs by the user. In 
this case the application asks the user (via the display medium or acoustically) to enter in- 
formation. Secondly, the user can take the initiative and make an input (e.g. choice of menu 
guide), which the subsystem input/output passes on to the appropriate application. 

Has the input been requested by the application, the subsystem input/output can tell where 
to- transfer the information from the sender's address. Has the user initiated the input, the 
information can only be sent to those applications that are known to the interpreter (by defi- 
nition or because the application has been registered). Depending on the availability of in- 
put/output units the subsystem input/output provides a suitable user guide for inputs initiated 
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by the user; it also controls user requests and fo.lows user commands. Depending on how 
the devices are actually implemented, the user will be able to see al. available applications 
on display before deciding on a menu. 

If an application receives the message ..menu" i, will transfer all menu items of its main men, 
W available) to the subsystem input/output. This procedure is necessary, because otherwise 
a selector, of menu items cannot be presented conveniently on a larger display. Like the 
other ,n P ut requests the menu items wil, be transferred as defined types of information. Mo- 
reover, it is possible to transfer one or more menu item as a sequence c, ASCII characters 
Has the user decided on one item, the number of the submenu wil, be sen, to the chosen 
apphcahon as the input result. The application then transfers a„ menu items of the submenu 
Of avertable) ,0 the subsystem input/output. This procedure w«f continue until the user has 
reached the lowest menu ievei. has decided on one menu item or has called off the menu 
guide. 

If an app.ica.ion wants to ask the user to make an input, it has to occupy the input medium. I. 
the med,um is available and has no, already been occupied by another appiication, i, will be 
occup,ed by the subsystem input/outpu, on behalf of the application making the request i e 
■it » no. available any ionger for inpu, reques,s by other app.ica.ions. The application then 
sends an ,npu, request to the subsystem input/output, which wil, be indicated to the user eit- 
her optically or acoustically. The data input by ,he user is transferred to the application Once 
he interaction between user and app.ica.ion has been competed, the inpu, medium is re- 
leased by the application. 

Actuation may occur where the inpu, medium is already occupied ei«her by an application 
requestmg or a user initiating an input. A,, inpu. requests have the same medium priority i e 
an ,npu, reques, canno, be interrupt by another. „ ,he inpu, medium is occupied 'the 
app,,ca ,r ■ receives a negative message. „ is ,hen up to the application to repeat the inpu, 
request at a later point. P 

input requests can be interrupted by output requests o, a higher priori,y. „ ,ha, happens i, ,s . 

respons,b ity o, the subsystem inpuUcutpu, to store the inpu, reques, and ,he information 
ha, , he user has en.ered up to ,ha, pen, for ,he dura,ion o, ,he disrup«ion. „ the priority o, 
he output reques, changes and ,a„s below ,ha, o, ,he inpu, reques,, ,he s,ored inpu, reques, 
» Present again. , npu , and ou.pu, ,eques,s are ,rea,ed d i( ,eren„ v because i. ,s ,moor,a 
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that the inputting procedure can be interrupted if high priority information have to be dis- 
played (e.g. incoming traffic data) while in the case of input requests disruptions would only 
confuse the user. 

Again it is important to make sure that the information is displayed for a certain minimum 
length of time, even in the case of interruptions. Moreover, each change of information on 
the display has to be economically sensible and easily recognizable by the user. 

The precise sequence of events is described in chapter 3.2.6 below. 
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2.2.5 Genera! Functions Routing + System Control 
2.2.5.1 Routing 

Routing is a oentrai (unctio n „, ,„ e base ternnina,. „ links ,na AP, i„, ert aoe with tne base 
funCons. „ portor™ the tasks o, the distribution o, intonation in the Mowing direotions: 

- from applications to base functions 

- from base functions to applications 

- between applications 

- between base functions 

birr T Ca "° nS ^ i0 ' m aCOe " '° * he b35e «** - -ess to the 
base functions has to be coordinated. 

Routing from application services to base functions 

t m :^Z " ^ °" '° *» ^se tunotions. 

sea on via the API interface (see chapter 3.2.1). 

If an app.ication tries to gain access to a faulty component of the terminal, it wi„ receive an 
error message issued by the system control. 



Routing from base functions to application services 

.Ration that has to be transferred from the base functions to the action serv,ces in- 
- information generated by the base functions themselves 
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- incoming information from external centers (in the subsystem communication) 

- data entered by the user or initiated by the application (in the subsystem input/output) 

Routing is carried out by means of an internal allocation of addresses; its function is to eva- 
luate and pass on source and destination addresses in the superframe of a message (see 
chapter 3.2.1). 

If the routing function receives a message from a service center via a GSM module, it has to 
evaluate the Application Service Identifier (ASI) contained in the message {the ASI is the 
same for all the service centers and terminal applications) and determine the appropriate 
destination address in the terminal in order to pass the message on. In the case of a messa- 
ge being transferred from a terminal application to a service center, the procedure is the sa- 
me, i.e. the message contained in the ASI has to be evaluated in order to pass the message 
on to the correct center. 
Routing between applications 

If the header of the frame received via the API interface contains the address of an applica- 
tion identifier, the message is transferred to the application addressed. In this case the base 
function will not be addressed. 



Routing between base functions 

It is possible in principle to exchange messages between base functions. For example, sta- 
tus information regarding the GSM module (e.g. signal strength) can be transferred directly 
to the subsystem input/output. 



2.2.5.2 System Control 

To operate the base terminal functions are necessary that run independently from the traffic 
telematics applications. These functions are: 
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initialization of system 

initialization and control of applications 

- guidance and control of status (hardware and software) 
built-in . test and diagnosis 

- power management (warm start, cold start, power down, emergency shut- 
down) 

software versions management 
error management 

The majority of functions will be implemented by the manufacturer in accordance with the 
terminal structure. The base functions for this complex of functions have as yet to be desert- 

bed in detail. 

Error Management 

The error management covers all measures that are taken to recognize, record and correct 
errors and to inform the user, .t includes status request and status control of hardware base 
functions and applications. Furthermore, once errors are recognized measures will be iaken 
■f possible, to correct them (e.g. reset and restart). 

The watchdog supervises all app.ications that have been registered and. if necessary, resets 
them. 



Keeping an error protocol 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



sro 

A base function is to be implemented in order to record errors which occur in the base termi- 
nal. 

If an error is discovered the base function is informed. When addressing the base function 
parameters will be transferred, which will be filed into the error protocol. 

Possible parameter are 

- time stamp, 

- error code, 

r error classification, 

- faulty component (hardware unit, software module) and 

- measures introduced to correct errors. 

The error log book can be read by a service point. Data are transferred via the SCI 
(Standard Communication Interface). 

The mechanisms and parameter of the error protocol are yet to be determined. 
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2.2.6 Priority Management 



Priority management becomes necessary whenever more than one application requires ac- 
cess to the same resource. Besides the system's internal resources such as memory and 
computing time the applications also need access to the base functions. The management 
of internal resources is undertaken by the operating system and will receive no further con- 
sideration in this specification. 

The concept for this system is based on the premise that applications should have indepen- 
dent access to the base functions and that several applications should be able to use these 
funct.ons at the same time. Certain requirements have to be fulfilled in order to create such a 
system (e.g. multitasking systems and applications). 

The priority management guarantees that in the case of high priority base function calls 
ex.st.ng allocations of resources within the system can be adjusted to meet the demands of 
the current situation. 

Base functions that regulate the access to resources are subjected to the priority manage- 
ment. Resources to be considered are 

- the subsystem communication, 

- the subsystem access control, 

- the subsystem input/output. 

- the Standard Communications Interface (SCI). 

The subsystem location is not subjected to the priority management. 

The priority management can be implemented either individually for each resource or central- 
ly for all base function calls together, depending on factors such as software design and rea- 
son, operating system. However, this cannot and should not be specified at this point. 

Regulations will have to be set up to make sure that on.y certain high priority applications are 
allowed to run. Furthermore, applications which are connected via the SCI have to follow 
these rules as well. 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



*2 

3 Application Programming Interface (API) 
3.1 Overview 

The Application Programming interface (API) 1 is an open interface, accessable and useful 
for every provider which conforms to the API specification. The API allows the implementati- 
on of today's and future applications. Applications can be manufacturer specific integrated 
as a part of the IntraGSM base device to create a cost-efficient device. Nevertheless, the 
base device has to be equipped with a powerfu ( interface conforming to API specifications to 
serve applications made by other suppliers. The API supports the following communication 
interactions: 

1 . from the subsystems of the base device to the application modules 

2. from the application modules to the subsystems of the base device 

3. from the service centers to the application modules (via subsystem communication) 

4. from the application modules to the service centers (via subsystem communication) 

5. between application modules of the same manufacturer as well as between application 
modules of different manufacturers (i. e. the waypoint algorithm is used jointly by 'the 
application modules dynamic route guidance and floating car data acquisition). 

Besides the software interface a universial cost-efficient hardware interface, the Standard 
Communications Interface (SCI), is specified. The SCI expands the facilities (for processing 
and functions of the base device configuration by adding further services. 

The base functions of the different subsystems are initialised by API calls that are defined in 
the following sections as ..messages". These calls have a special frame structure which is 
called API Super Frame Structure. 



1 The API should not be changed by mistake with the GSM API. 
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3.2 API Frame Structure 

The super frames are used for data exchange between the applications and the base functi- 
ons and among each other. The super frames contain the messages to be transferred via 
the API. All super frames consist of a header and a message. All frames have the same 
header structure generated either by an application or by a base function. Each message 
has a general structure with a set of parameters depending on the messagetype. 



3.2.1 Super Frame structure 



General structure: 



<SRC>, <DEST>, <TRANS_NO>, <PRIO>, <TIME>, <message> 



Description: 
<SRC>: 

<DEST>: 

<TRANS NO>: 



<PRIO>: 



the identifier of the source of the super frame. It indicates the applicati- 
on or the base function initiating the transfer of the super frame. 

the identifier of the destination of the super frame. It indicates the 
application or the base function that is to receive the super frame. 

the transaction number is a serial number. It is used within responses 
for unique reference to a command previously received. Furthermore, it 
is useful when several applications use one GSM connection line 
(multiple access). 

the priority indicator in a super frame. It has to be evaluated by the 
priority management to solve conflicts in case of concurrent access to 
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the same base function. The priority indicator is not evalued in messa- 
ges from base functions towards the applications. Further on it is not 
evalued in messages related to the Subsystem Location. 

<TIME>: a time stamp, that is used e.g. for time dependent change of priority 

level or watchdog function. 

<message>: the message shall be transferred via API and processed at the addres- 

sed application or base function. The message is structured individually 
for each module and described in separate sections. 

The values for the super frames are defined in Annex 4. 
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3.2.2 General structure of the messages 

The messages within the super frames have an individual structure. 
Generally, for each message exists 
a name, 

(e.g. ,.cim_data_transfer_req") 

a message_id, 

a list of parameters (optional) 



Each message name has a characteristic prefix: 

gsm_ for GSM related messages 
9PS_ for GPS related messages 

cim_ for Chipcard Interface Module related messages 
<o_ for Input/Output related messages 



Each message name has a characteristic postfix: 



_req for requests 

_res for responses (i.e. answers to a request) 

_con for confirmations (e.g. as intermediate response) 

_ack for acknowledgement (when a request has been executed) 

_<nd for indications (i.e.spontaneous event indication) 

_rej for rejects (e.g. by the priority management) 
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General structure of the message: 

<msg_id>, [<par_1>, [< par_2> F „.[<par_n>]]] 

Description: 

<msg_Jd>: the unique identifier of the message. It is proposed to be a byte value. 
<par_x>: the parameter(s) of the message, as many as needed 

3.2.3 Messages related to the Subsystem Communication 

The following sections describe the messages used to request the GSM related base functi- 
ons, the responses and the unsolicited indications generated by the base functions or recei- 
ved by the application center. 

It is recommended to use GSM devices following the GSM 07.07 [2] and the GSM 07.05 [3] 
standards. 

A set of commands using the at-command set described with GSM-Recommendation 07.05 
and 07.07 may be allowed at the API, but are not described here, e.g. the command +CPIN, 
that is sending a password to the GSM module, because those commands are not referred 
in this specification. 

The GSM activities take care of the entries in the Communications Service Table that is pro- 
vided by the subsystem communication. The Service Table shows, which data services are 
currently available and which of them are implemented in the communication device. 

All messages include the prefix gsm_ to indicate that the message parameters are fitted 

for the use of GSM communication. Messages for other communication devices such as in- 
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marsat or rnobitex need to be defined. They can use exactly the same structure but may re- 
quire different message parameters. 

The message transfer between applications and GSM base functions is handled by following 
messages: 

related to GSM base function gsm dialog 

- gsm_open_request 

- gsm_open_confirmation 

- gsm_open_indication 

- gsm_open_response 

- gsm_data_request 

- gsm_data_confirmation 
. - gsm_data_indication 

• gsm__status_jndication 

- gsm_close_request 

- gsm_close_confirmation 

- gsm_close_indication 

related to GSM base function gsm indirect AT command access 

- gsm_AT_command__request 

- gsm__AT_command_response 

related to GSM base function gsm communication service table access 
" 9sm_write_service_tabie_request 

- gsm_read_service_table__request 

" 9sm_ read_service_table_response 



Some examples of message transfers between an application and a GSM base function are 
described in time sequence diagrams on the following pages. 



Illustration 3.2.3-1: Time sequence diagram related to the GSM base function GSM dialog 
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Illustration 3.2.3-2: Time sequence diagram related to the GSM base function GSM dialog 



Illustration 3.2.3-3: Time sequence diagram related to the GSM base function GSM dialog 



Illustration 3.2.3-4: Time sequence diagram related to the GSM base function. GSM dialog 



Illustration 3.2.3-5: Time sequence diagram related to the GSM base function GSM dialog 



Illustration 3.2.3-6: Time sequence diagram related to the GSM base function GSM dialog 



3.2.3.1 Message „gsm_open_request" 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



„gsm_open_req" 
application 

base function gsm dialog 
M gsm_open_confirmation" 

This message is used by the application to initiate a communication with 
theservice center. In any case, wether a Bearer Service, a Short Mes- 
sage Service or Gerneral Packet Radio Service is used, this message is 
used before sending data. 

If the attempt to setup a connection is unsuccessful, the base function 
has to evaluate and/or forward the error causes (e. g. network error 
causes described in GSM TS 04.08, Table 10.86) and shall react in ac- 
cordance with GSM TS 02.07. 
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Syntax: 



With the receipt of this message by the base function a logical channel 
for communication between the application and the base function is 
established. A confirmation message containing the logical channel 
number or the possible error cause has to be sent to the requesting 
.application. If the application wants to communicate using SMS the 
..gsm_open_con"-message is generated immediately after receiving the 
..gsm_open_req"-message. If a BS2X should be used for communication 
the connection to the requested service center has to be established 

before the „gsm_open_con"-message is sent to the requesting applica- 

tion. 

If an error occures a „gsm_status_ind"-message is sent to the reque- 
sting application. 

The message contains the message identifier <msg_id>, the application 
servtce identifier <asi>, the communication service <service> the dial 
number <dia L string>. in case of Bearer Services the parameters 
<speed>. <name> and <ce>. The data elements <speed>. <name> and 
<ce> and their possible values correspond to chapter 6.7 of GSM 07.07. 
In case of SMS the message contains the SMS center address 
<SMS_center_address>. 

<msg_id>, <asi>, <service>, <dial_string>, ^peeo^, <name>, <ce>. 
<SMS_center_adress> 



Defined values: <msg_id> to be defined 



<asi>: 



application service identifier 
values must be defined for all possible traffic tele- 
matics applications. As a minimum values must be 
defined for: 

- dynamic route guidance 

- floating car data acquisition 

- fleet management 
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- traffic information 

- emergency break down services 

- vehicle theft protection 

- automatic tolling 



<service>: 



service to be used for communication 
recommended values are: 

0 - Bearer Service (requires values for 

<dial_string>, <speed>, <name>, <ce>) 

1 - SMS (requires values for <diaLstring>, 

<SMS_center_address>) 



<diaLstring>: 
<speed>: 



dial number of the requested service center 

selection of data rate and information transfer 
capabilities 

recommended values (as defined in chapter 6.7 of 

GSM 07.07) are: 

4 - 2400 bps (V.22bis) 

7 - 9600 bps (V.32) 

68- 2400 bps (V.110) 

71- 9600 bps (V.110) 



<name>: 



selection of Bearer Service 

recommended values (as defined in chapter 6.7 of 

GSM 07.07)are: 

0 - asynchronous modem 



<ce>: 



selection of connection element 

values (as defined in chapter 6.7 of GSM 07.07) 

possible values are: 

0 - transparent 

1 - non-transparent 



<SMS_center_address>: dial number of the requested SMS center 
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3.2.3.2 Message „gsm_open_confirmation' 



Message name: „gsm_open_con" 



Source: 

Destination: 

Description: 



Syntax: 

Defined values: 



base function gsm dialog 
requesting application 

This message is used to confirm that a logical channel is opened for the 
requesting application to send data to the service center (with a 
,,gsm_data_req"-message). The „gsm_open_con"-message contains a 
<channel_no>. This <channel_no> is used by following messages to 
adress the logical communication channel. 

In case of unresolvable problems e. g. connection not established after 
the defined numbers of retrails the base function indicates the reason of 
failure with a ,,gsm_statusjnd"-message. Consequently if no* logical 
channel is opened, no .,gsrr L open_con"-message is be sent to the 
application. 

<msg_id>, <channel no> 



<msg_id>: 



<channel no>: 



to be defined 

identifier of the logical communication channel for 
the requested communication 



3.2.3.3 Message ,,gsm_operMndication' 



Message name: „gsm_open_ind" 
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Source: 

Destination: 

Description: 



base function gsm dialog 



application 



This message is used by the base function to indicate to the destination 
application that a service center wants to send data. 



If the service center originates a connection-oriented communication, 
the base function receives an identifier for the destination application. 
The base function opens a logical communication channel to this appli- 
cation and sends the channel number. The application has to confirm 
the message with the response message , t gsm__open__res", which is 
transferred by the base function to the requesting service center. 

If a service center call using SMS is received by the traffic telematics 
terminal, a logical communication channel to the destination application 
is established by the base function as well. Again the application has to 
confirm with the „gsm_open_res M -message before the data are indicated 
by the base function. 



Syntax: 

Defined values: 



<msg_id>, <channel_no> 



<msg_id>: 



to be defined 



<channel no>: 



identifier of the logical communication channel for 
the requested communication 



3.2.3.4 Message „gsrn_operwesponse u 



Message name: „gsm_open_res M 



Source: 



application 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT7EP96/01110 



Destination: 
Description: 

Syntax: 



b3 



base function gsm dialog 



This message is used to confirm to the base function that the application 
is ready to receive a message from a service center. 

<msg_jd>, <channel no> 



Defined values: <msg__id>: 



to be defined 



<channel__no>: identifier of the logical communication channel for 
the requested communication 



3.2.3.5 Message „gsm_data_requesr 



Message name: „gsm_data_req" 



Source: 



Reply: 



Description: 



application 



Destination: base function gsm dialog 



, t gsm_-data_con'* 

With this message data to be transmitted to the service center is sent to 
the base function. 



In case of successful transmission a ,,gsm„data_confimation''-message 
is sent to the application. 



In case data can not be transferred, correctly by running through the 
retrail mechanisms a ,.gsm_status_ind'<-message is sent io the applicati- 



on. 
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Syntax: 



<msg_id>, <channeL.no>, <data_length>, <data> 



Defined values: <msg__id> 



to be defined 



<charinei_no>: identifier of the logical communication channel for 
the requested communication 

<data_length>: length of the <data> in byte 



<data>: 



data to be sent to the service center 



3.2.3.6 Message „gsm_data_confirmation" 



Message name: „gsm_data_con" 



Source: 



base function gsm dialog 



Destination: 



requesting application 



Description: 



This message is used to confirm to the requesting application that data 
has been sent to the service center. 



If data are transmitted using SMS a „gsm__data_con"-message is sent to 
the application when the transmitted message is acknowledged by the 
SMS service center. If data are transmitted using a connection oriented 
communication a confirmation of the delivery to the service center is gi- 
ven by the end-to-end protocol. 



Syntax: 

Defined values: 



<msg_id>, <channel_no> 



<msg_id>: 



to be defined 
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3.2.3.7 Message „gsm_dataJndication" 

Message name: „gsm_data_ind" ' 
Source: base function gsm dialog 

Destination: application 

Description: With this message an application is informed about a message received 

from a service center. The service center has originated a connection to 
send data to an application. 

The base function receives this data of the service center and identifies 
the destination application. If there is already a logical channel opened 
to this application the data are transferred by using this channel. If there 
is no open channel, a channel has to be established by the base functi- 
on. Using this new channel the received data are transferred to the 
application. 

When within an existing communication a service center sends data to 
the terminal equipment, the base function receives this data and identi- 
fies the destination application the data has to be sent to: 

If within an existing communication the destination application already 
has an open communication channel this channel number is part of the 
,,gsm_datajnd u -message. If the destination application doesn't have an 
open communication channel a new logical communication channel is 
generated by the base function. 

When a service center originates a connection-oriented communication 
the base function confirms the connection automatically and generates 
a logical communication channel to the destination application. After the 
service center has sent the data, the base function sends a 
„gsm_data_ind"-message to the destination application; 
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When a service center originates a connectionless communication the 
base function receives the data, generates a new logical communication 
channel and sends a „gsm_data_ind"-message to the destination appli- 
cation. A .,gsm_get_data_con"-message is sent from the application to 
the base function for confirmation. The base function does not sent a 
confirmation message to the service center. Only the application has to 
decide if the service center, needs a confirmation and has to initiate a 
new communication if needed. 



Syntax: 

Defined values: 



The message contains the message identifier <ms gJ d>, the data type 
<data_type>, the length of the following data <data_length>. the data it- 
setf<data> and the channel number <channel_no> 

<msg_id>, <channel_no>, <data_lengtfi>, <data> 



<msg_id> 



to be defined 



<channel_no>: identifier of the logical communication channel for 
the requested communication 

<data_length>: length of the <data> in byte 



<data>: 



data to be sent to destination application 



3.2.3.8 Message „gsm_status__indication" 



Message name: „gsm_status ind" 



Source: 



base function gsm dialog 



Destination: 



application 
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Description: 



This message is used to inform the application about an error (values 
acc. to GSM TS 04.08 Table 10.86 and GSM TS 07.07 section 9.2) or 
an unexpected action occured or about a status change of the equip- 
ment. 



When receiving the „gsm_status_ind u -message the application has to 
decide about the further actions. 

The message contains the message identifier <msg_id>, the status in- 
formation <status> and the channel number <channel_no> (if available) 



Syntax: 

Defined values: 



<msg_id>, <channeLno>, <status> 



<msg_id> 
<channel no>: 



to be defined 

identifier of the logical communication channel for 
the requested communication 



<status>: 



status information concerning an error, an unex- 
pected action or equipment status, 
possible values are defined in annex 1 : 
### - status information 
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3.2.3.9 Message „gsm_close_request' 



£3 



Message name: „gsm_cIose_req" 



Source: 

Destination: 

Reply: 

Description: 



Syntax: 

Defined values: 



application 

base function gsm dialog 

„gsm_close_con" 
»gsm_status_ind" 

This message is used by the application to close the logical communi- 
cation channel between the application and the base function. A con- 
nected communication line is disconnected immediately if no other 
communication path (logical channel) is opened. 

<msg_id>, <channel no> 



<msg_id> 



to be defined 



<channeLno>: identifier of the logical communication channel for 
the requested communication 



3.2.3.10 Message ,,gsm_close_confirmation* 



Message name: ..gsir^close^con 1 ' 



Source: 



base function gsm dialog 



Destination: 



application 
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Description: This message is used to confirm to the requesting application that the 

logical communication channel between the application and the base 
function has been closed. The communication with the service center 
has been terminated in case of no other communication path (logical 
channel) was opened. 

Syntax: <msg_id> ( <channel_no> 

Defined values: <msg_id> to be defined 

<channeLno>: identifier of the logical communication channel for 
the requested communication 



3.2-3,11 Message „gsm_close_indication' 



Message name: 
Source: 
Destination: 
Description: 



„gsm_close_ind" 

base function gsm dialog 

application 

This message is used by the base function to indicate to an application 
that the communication identified by the logical channel number to the 
service center is terminated. 



If a service center wants to disconnect a connection-oriented communi- 
cation a close request is sent to the traffic telematics terminal. When the 
end-to-end protocoll of the base function receives this request, a confir- 
mation is sent immediately to the service center. To indicate the discon- 
nect a n gsm_close_ind ll -message is sent to the related application. The 
logical channel is closed. 
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.When within a connectionless communication no data are received for a 
time duration „r\ also a „gsm_close_ind ,4 -message is sent to the related 
application to close the logical communication channel. 

Syntax: <msg_id>, <channel_no> 

Defined values: <msg_id> to be defined 

<channeLno>: identifier of the logical communication channel for 
the requested communication 



3.2.3.12 Message ngsm^AT^command^requesr 



Message name: „gsm_AT_command_req" 



Source: 



application 



Destination: 



base function gsm indirect AT-command access 



Reply: 



»gsm_AT_command_res" 



Description: 



This message is used by the application to send an AT command to a 
GSM base function, transparently. AT commands shall be in accordance 
with GSM-recommendation 07.05 and 07.07. To send a 
gsm_at_command_req no logical channel is requested. The command 
can be used parallel to opened channels. 



Not all AT commands are allowed by this command. E. g. the ATD 
command can only be generated by the base function itself after a 
gsm^open_request (see annex 2 2 ) 



Note: Only for the here defined indirect access to the gsm module using the superframe structure some of the 
AT commands are not allowed. In case of direct access, e. g. by external PC or faxes anv AT command can direct- 
ly address the gsm device without using the gsm AT command messages and the superframe structure 
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Syntax: <msg_id>, <crndjen>, <AT__command> 

Defined values: <msg_id> to be defined 

<cmd_len> length of the command that follows 

<AT_command> AT command to be sent to the base function. The 
set of possible commands is recommended in an- 
nex 2. 



3.2.3.13 Message „gsm AT_command__response" 



Message name: „gsm - AT_command_res" 



Source: 

Destination: 

Description: 



Syntax: 



base function gsm indirect AT-command access 
concerned application 

This message is used by the GSM base functions to send the response 
of an AT command received by the GSM module to the addressed 
application transparently. 

<rnsg_Jd> ( <data_length> f <data> 



Defined . : ; ues: <msg_id> 



to be defined 



<data_length>: length of <data> in byte 



<data>: 



data to be sent by the base function 
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3.2.3.14 Message „gsm_write_service_table_requesr 



Message name: „gsm_write_service._table_req" 



Source: 
Destination: 

Description: 



Syntax: 



application 

base function gsm communication service table access" 

This message is used to write/change the contents of the communicati- 
ons service table, which is under control of the base function. To send 
this message no logical channel is required. The command can be used 
in parallel to opened channels. 

<msgjd>, <object> ( <service>, <status>, <data> 



Defined values: <msg_id> 



to be defined 



<object> 



selector for <service> 
recommended values are: 

1 - network 

2 - GSM-module 

3 - subscriber 

4 - call repeat counter 

5 - calling line identity of service center applicati- 

on 



<service/dial_string> selector for service or dialling information 
recommendation for requested values are: 
case of <object> value is 1 ,2 or 3 the availability 



in 



can be set for: 

- BS24 

- BS26 

- TS11 

- TS21 
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- TS22 

- TS23 

- GPRS/PDS 

- CLIP 

- CLIR 

- COLP 

- COLR 

- Call Wait 

in case of <object> value is 4, the value of 

<service> is the dial_string for which the call 
repeat counter is to be set to a specific value 

- dial_string for ..call repeat counter 
in case of <object> value is 5. the value of 

<service> is the applicationjd for which the 
calling line identity is to be set. 

- application-id for calling line identity 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



data to be written to the communication service ta- 
ble. 

recommended values are: 

in case of <object> value is 1 ,2 or 3, following 
values are recommended 

0 - unknown 

1 - available 

2 - not available 

in case of <object> value is 4, following values 

are recommended 

# - value of call repeat counter 

in case of <object> value is 5, following values 

are recommended 

„calling_line_identity" for service center appli- 
cation 



3.2.3.15 Message „gsm_read_service_table_request' 



Message name: „gsm_read_service table 



Source: 
Destination: 
Reply: 
Description: 



:_req" 



application 

base function gsm communication service table access" 
„gsm_read_service_table_res" 

This message is used to read data out of the communication service 
table, which is under control of the base function. The result is sent to 
the requesting application using the message 
gsm_read_service_table_ind. To send this message no logical channel 
is required. The command can be used in parallel to opened channels. 
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Syntax: 



<msg_id>, <object>, <service/dial_string> 



Defined values: 



<msg_id> 



to be defined 



<object> 



selector for <service> 



recommended values are: 

1 - network 

2 - GSM-moduie 

3 - subscriber 

4 - call repeat counter . 

5 - calling line identity of service center applicati- 



on 
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<service/dial_string> requested service or dial_string information 
recommendation for requested values are: 
in case of <object> value is 1,2 or 3 service infor- 
mations can be requested for: 

- BS24 

- BS26 

- TS11 

- TS21 

- TS22 

- TS23 „ 

- GPRS/PDS 

- CLIP 

- CLIR 

- COLP 

- COLR 

- Call Wait 

in case of <object> value is 4 the call repeat counter 
values for a specific dial_string can be reque- 
sted 

- dial_string for ..call repeat information" 

in case of <object> value is 5 the calling line identity 
of a specific service center for a traffic tele- 
matics application can be requested 

- application-id for request of calling line 
identity 



3.2.3.16 Message ,,gsm_read_service_table_response" 

Message name: ,.gsm_read_service_table res- 



Source: baS e function gsm communication service table 



access 
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Destination: 
Description: 



Syntax: 

Defined values: 



application 

This message is used to send the result of a 
„gsnrwead_service__table_req" to the requesting application. 

The message contains the message identifier <msg_id> and the status 
of the requested service <status>. If the call repeat counter of a di- 
aLstring is requested, the message also contains the actual counter 
value <counter>, the time of the last attempt <time> and the release 
cause <reason>. If the calling line identity of a specific service center for 
a traffic telematics application is requested, the message also contains 
a calling line identity <CLI>. 

<msg_id>, <status>, <counter>, <time>, <reason>, <CLI> 
<msg_id> to be defined 

<status>: status of the requested service 



possible values are: 



0 - 



unknown 



1 - available 



2 - 



not available 



<counter>: 



actual value of the repeat counter 



<time>: 



time of last attempt 
possible values are: 
time [hh:mm:ss] 



<reason>: 



release cause 



possible values are: 

# - release causes in accordance with GSM re- 



commendations 04.08, 07.05 and 07.07 



<CLI>: 



calling line identity of the service center for the re- 
quested traffic telematics service. 
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3.2:4 Messages related to the Subsystem Location 

in this chapter the messages related to the different GPS base functions are decribed The 
message transfer between applications and op<5 f uecr.oea. me 

app.,cat.ons and GPS base funct.ons .s handled with the follo- 
wing messages: 

related to GPS base function GPS base data: 

- gps_data_start_request 

- gps_data_indication 

- gps_data_stop_request 

- 9P s -Send_dgps_correct_indication 

- 9Ps_data_set_height_request 

- gps_data_del_height_request 

related to GPS base function geometry: 

- 9PS_geometry_request 

- 9PS_geometry_indication 

related to GPS base function approximation: 

- 9PS_approx_data_backward_request 

- gps_approx_data_backward_indication 

related to GPS base function waylenght: 

- gps_waylength_start_request 

- gps_waylength_request 

- gps_waylenght_indication 

- 9PS_waylength_stop_request 

- 9PS_waylength_global_request 

- gPS_waylenght_globaLindication 

related to GPS base function waypoint: 

- gps_waypoint_start_request 

- 9PS_waypoint_status_indication 

- 9Ps_waypoint_stop_request 
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Some examples of message transfers between an application and a GPS base function are 
decribed in time sequence diagrams on the following pages. 



Illustration 3.2.4-1: Time sequence diagram related to the GPS base functions GPS base 

data and approximation 



Illustration 3.2.4-2: Time sequence diagram related to the GPS base function waylength 



Illustration 3.2.4-3: Time sequence diagram related to the GPS base function waypoint 
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3.2.4.1 Message "gps_data_start_request M 



Message name: "gps_data_start_req M 



Source: 



application (or other base function) 



Destination: 



base function gps base data 



Description: This message is used to request the GPS data sets. 

If the parameter <par> has the value 0, only the current GPS data set is 
requested. If <par> has the value 1 , the current GPS data set is reque- 
sted to be sent and the following every <time_diff> seconds. 

With the bitmap <mask> the application specifies the specific data ele- 
ments of the whole GPS data set which are needed. 



Syntax: 



<msg_id>, <par>, <time_diff>, <mask> 



Defined values: <msg_id>: 



to be defined 



<par>: 



0 only the current GPS data set is requested 

1 the current GPS data set is requested and 
the following every <time_diff> seconds 



<ttme diff> 



time duration between two requested GPS data 
sets 



<mask> 



bitmap that indicates the specific data elements 
which are requested by the application. The whole 
GPS base data set contains the elements: 
date, 

time (UTC), 
geographic longitude, 
geographic latitude, 
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height (Measured Sea Level), 
Horizontal Dilution of Precision (HDOP), 
Estimated Position Error in direction south- 
north (EPE(x)), 

Estimated Position Error in direction west- 
east (EPE(y)), 
absolute horizontal velocity, 
heading (0 degrees=north, clockwise), 
number of theoretically visible satellites, 
number of satellites that are regarded for 
the position calculation, 
indicator for a change of satellite constella- 
tion (0=np change of constellation, 
1 =change of constellation) , 
Type Of Position (TOP), 
specific data of receiver, 
pseudorange data, 
pseudorange rate 



3.2.4.2 Message M gps_data_Jndication 



Message name: 



ii 



gps_data_Jnd' 



Source: 



base function gps base data 



Destination: 



application (or other base function) 



Description: 



This message is used to send the specific data elements <data_set> of 
the current GPS data set which are requested by the application(s). 



The positions of the current GPS data set could either be valid positions 
measured by the GPS receiver or forward approximated positions of the 
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base function approximation. The specific data elements that are sent 
are chosen by the requesting application (see message 
„gps_data_start_req") and indicated by the bitmap <mask>. 

If more than one application request data elements of the GPS data set. 
all requested data elements are sent to all applications by this one mes- 
sage. The specific data elements that are sent are indicated with the 
bitmap <mask>. Each application needs to select those data elements 
that it has requested. 

If the parameter <par> of the message „gps_data_start_req" has the 
value 1. also the data elements of the following GPS data sets, specified 
by the bitmap <mask>, are sent every <time_diff> seconds. 



Svntax: <msg_id>, <mask>, <data_set> 

Defined values: <msg_id>: to be defined 



<mask> bitmap that indicates the specific data elements of 

the whole GPS data set that are sent. 

<data_set>: specific data elements of the whole GPS data set 

indicated by the bitmap <mask> 



3.2.4.3 Message "gps_data_stop_request" 

Message name: "gps_data_stop_req" 

Source: application (or other base function) 

Destination: base function gps base data 
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Description: 



This message is used to stop the transfer of the GPS data sets. If there 
are other applications still requesting GPS data sets, they are served 
until they send this message, too. 



Syntax: 



Defined values: 



<msg_id> 
<msg_id>: 



to be defined 



3.2.4.4 Message ,,gps_send_dgps_correct_indication 4 



Message name: „gps_send_dgps_correct_ind u 



Source: 



base function gsm dialog or application 



Destination: 



base function gps base data 



Description: 



If an application can provide for correction data (DGPS) this message is 
used to send the differential data for DGPS positions (in format RTCM) 
to the base function gps base data. 



Syntax: 



<msgjd>, <dgps_data> 



Defined values: <msg_id> 



to be defined 



<dgps_data>: 



differential data for DGPS positions (in format 
RTCM) 



3.2.4.5 Message M gps__data_set_height_request" 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



Message name: , 'gps_data_set_height_req" 



Br 



Source: 

Destination: 

Description: 



Syntax: 

Defined values: 



application (or other base function) 
base function gps base data 

■f an application knows the exact height of the current GPS position it is 
ab.e to provide the exact height with this message. »n addition the app.i- 
cat,on sends the radius of the circle around the current position in which 
the fixed height is still exact. 

The base function GPS base data checks by eva.uating the current ve- 
locty and the time step if the following position is still inside the circle If 
so ,t futes this height at the GPS receiver that is now ab.e to generate a 
more accurate GPS position with this additional information. 

With every new GPS data set this check is repeated. If the next position 
•s outs.de the circle the base function deletes the fixed height at the 
GPS receiver. Also the application can delete the fixed height with the 
message „gps_data_del_height_req". 

The fixed height is indicated to all applications that request GPS data 
sets with the Type Of Position (TOP). 

<msg_id>, <height>, <radius> 



<msg_id>: 

<height>: 

<radius>: 



to be defined 



fixed height 



radius of the circle around the current position 
which the fixed height is exact. 



in 
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3.2.4.6 Message "gps__data_del_height_request M 



Message name: "gps_data_deLheight_req n 



Source: 



application (or other base function) 



Destination: 



base function gps base data 



Description: 



With this message the application that has fixed the height of the GPS 
position deletes the fixed height. 



Syntax: 



<msg_id>, <height> 



Defined values: <msg_id>: 



to be defined 



<height>: 



fixed height that has to be deleted 



3.2.4.7 Message "gps_geometry_request" 



Message name: "gps__geometry_req M 



Source: 



application (or other base function) 



Destination: 



base function geometry 



Description: 



This message is used to request the distance or angle between two 
positions. 



With the bitmap <calo the calculation of the radial distance, the longi- 
tudinal distance, the latitudinal distance and/or the angle between the 
two positions can be requested. 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



Syntax: 

Defined values: 



If the parameter <pos> has the value 2, the two positions are given by 
the application. If the paramter <pos> has the value 1, one position is 
given by the application and the other one is the current position. 

<msgjd>, <cato, <pos>, <position> 



<msg_id>: 



to be defined 



<calo: 



bitmap that indicates the reqested calculations. The 
following calculations are possible: 

radial distance, 

longitudinal distance, 

latitudinal distance, 

clockwise angle between the two positions 
related to north 



<pos>: 
<position>: 



2 two positions are given by the application: 
long! Longitude of position 1 
Iat1 Latitude of position 1 

long2 Longitude of position 2 
Iat2 Latitude of position 2 



<pos>: 
<position>: 



1 one position is given by the application, 

the other one is the current position: 
longl Longitude of position 1 
Iat1 Latitude of position 1 
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3.2.4.8 Message n gps__geometryJndication ,, 



Message name: "gps_geometry_ind' , 



Source: 

Destination: 

Description: 



Syntax: 



base function geometry . 
application (or other base function) 

This message is used to send the result(s) of the distance and/or angle 
calcutation(s) between two positions, which was requested by the mes- 
sage ,, gps_geometry_req , \ 

<msg_id> ( <calc>, <result_data> 



Defined values: <rnsg_jd>: 



to be defined 



<calo: 



bitmap that indicates the result(s) of the calculati- 
ons) 



<resuit_data>: result(s) of the distance and/or angle caiculation(s) 
(see message „gps_geometry_req") 



3.2.4.9 Message n gps_approx_data_backward_request" 



Message name: "gps_approx_data_backward_req" 



Source: 



application (or other base function) 



Destination: 



base function approximation 
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Description: 



Syntax: 

Defined values: 



83 

After receiving forward approximated or invalid positions and then the 
first new valid position, an application can request the backward 
approximated positions of the gap with this message. 

With the bitmap <mask> the application specifies the specific data ele- 
ments of the whole GPS data set which are needed. 

<msg_id>, <time_diff>, <mask> 



<msg_id>: 



to be defined 



<time diff> 



time duration between two requested GPS data 
sets 



<mask> 



bitmap that indicates the specific data elements 
which are requested by the application. The whole 
GPS base data set contains the elements: 
date, 

time (UTC), 
geographic longitude, 
geographic latitude, 
height (Measured Sea Level), 
Horizontal Dilution of Precision (HDOP), 
Estimated Position Error in direction south- 
north (EPE(x)), 

Estimated Position Error in direction west- 
east (EPE(y)) f 
absolute horizontal velocity, 
heading (0 degrees=north, clockwise), 
Type Of Position (TOP), 
specific data of receiver 



Message "gps_approx_data_backward_indication" 
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Message name: "gps_approx_data_backward_ind n 



Source: 

Destination: 

Description: 



base function approximation 



application (or other base function) 



With this message the base function GPS base data sends a number of 
N_pos backward approximated positions of the latest gap to the appli- 
cation. 



Syntax: 



The specific data elements that are sent are chosen by the requesting 
application (see message „gps_approx_data_backward_req") and indi- 
cated by the bitmap <mask>. 

<msg_id>, <mask>, <tirne_diff>, <N_pos> T 
<data_set_1 ;data_set_2; ... ;data_set_N_pos> 



Defined values: <msg_id>: 



to be defined 



<mask> 



bitmap that indicates the specific data elements of 
the backward approximated GPS data sets. The 
bitmap is valid for each of the data sets. 



<time diff> 



time duration between two requested GPS data 
sets 



<N_pos>: 



number of backward approximated positions that 
are sent 



<data_set_1;data_set_2; ... :data_set_N_pos>: 

the backward approximated data sets that are sent. 
Each data set contains the specific data elements 
that are indicated by the bitmap <mask>. 
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3.2.4.11 Message "gps_waylength_start_request' 



Message name: "gps_waylength_start_req" 



Source: 



application (or other base function) 



Destination: 



base function waylength 



Description: 



This message is used to reset the waylength counter on the value „0 
meters" for incrementation or on a fixed waylength (as a negative value) 
that should be covered for decrementation (realized as incrementation 
of negative values). 



The application chooses counter marks <vaM,val_2 val_n> so that 

an indication is sent if.a mark is exeeded. 

I.e. the fixed waylength that should be covered is 2000 m, and indicati- 
ons should be sent if there are 200 m, 100 m and 50 m of the whole 
waylength left to cover. Then the application sets <start_vafc>= <- 
2000m> and <val_l , val_2, val_3, val_4> = 

<-200m, -100 m, -50m, 0m> in this message to get an indication at the- 
se points. 



The application sets a counter ID. The base function retains which way- 
length counter belongs to which application. 

The waylength calculation must be stopped by the application with the 
message „gps_waylength_stop_req". Only after this stop the waylength 
counter can be resetted. 
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Syntax: 



3* 

The waylength counter is stopped automatically by the base function if it 
crosses the counter value „0 meters". It is stopped at a fixed maximum 
value, too. 

<msgjd>, <counter_id>, <start_vat>, <n>, <vaM ,val__2 val_n> 



Defined values: <msg_Jd>: 



to be defined 



<counteMd> counter ID set by the application 



<start val> 



start value of the waylength counter. It is 0 meters 
for incrementation or a fixed waylength as a negati- 
ve value for decrementation. 



<n>: 



number of counter marks 



<vaM ,val_2,...,val__n>: counter marks 



3.2.4.12 Message n gps_waylength_request" 

Message name: "gps^waylengtlweq" 



Source: 

Destination: 

Description: 

Syntax: 



application (or other base function) 
base function waylength 

This message is used to request the current counter value of the coun- 
ter with the counter ID <counter_id>. 

<msg_id>, <counter_id> 



Defined values: <msg_id>: 



to be defined 
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<couriter id> 



counter ID 



3.2.4.13 Message ,, gps_waylength_indication' 



Message name: "gps_waylength_ind" 



Source: 

Destination: 

Description: 



Syntax: 



base function waylength 
application (or other base function) 

This message is used to send the current counter value of the counter 
with the counter ID <counter_id>. The message is sent after the request 
..gps_waylength_req" or if the current counter value has crossed one of 
the marks <val_1 . val_2, .... val_n> of the message 
„gps_waylength_start_req". 

<msg_id>, <counter_id>. <counter value> 
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Defined values: <msg_id>: 



to be defined 



<counter id> 



counter ID 



<counter__value>: the current counter value 



3.2.4.14 Message M gps_waylength_stop_requesr 



Message name: "gps_waylength_stop_req" 



Source: 

Destination: 

Description: 



Syntax: 

Defined values: 



application (or other base function) 
base function waylength 

This message is used to stop the waylength counter. If the parameter 
<par> has the value 1 f only the waylength counter with the counter ID 
<counter_id> is stopped. If the parameter <par> has the value 0 f all 
waylength counters set by the application are stopped. 

<msg_id>, <par>, (if <par>=1 : <counter_id>) 



<msg_id>: 



<par> 



to be defined 

0 all waylength counters set by the applicati- 
on are stopped 

1 the waylength counter with the ID 
<counter_id> is stopped 

<counter id>: counter ID 



3.2.4.15 Message ,, gps_waylength_global_request M 



RURSrmrTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



Si- 



Message name: n gps_waylength_global_req" 



Source: 



application (or other base function) 



Destination: base function waylength 



Description: 



This message is used to request the current counter value of the global 
waylength counter. 



Syntax: 



<msg id> 



Defined values: <msgjd>; 



to be defined 



3.2.4.16 Message ''gps^waylength^globaMndication' 

Message name: "gps_waylength_globaUnd" 



Source: 

Destination: 

Description: 



base function waylength 
application (or other base function) 

This message is used to send the current counter value of the global 
waylength counter. 



Syntax: 



<msgjd>, <global_counter_value> 



Defined values: <msg_id>: 



to be defined 



<globaLcounter_value>: the current counter value of the global 

waylength counter 
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3.2.4.17 Message n gps_waypoint_start_request" 

Message name: n gps_waypoint_start_req" 
Source: application (or other base function) 

Destination: base function way point 

Description: This message is used to initialize the base function "gps_waypoint n by 

sending the waypoint data. 

If the parameter <geom> has the value 1 , the data of a circle are sent 
(longitude and latitude of the circle center, radius, hysteresis, preferred 
direction (0 degrees=north F clockwise) and aperture angle of preferred 
direction). 

If <geom> has the value 2, the data of a rectangle are sent (longitude 
and latitude of the rectangle center, length and width of the rectangle, 
hysteresis, preferred direction (0 degrees=north, clockwise) and apertu- 
re angle of preferred direction). 

The application sets a waypoint ID. The base function retains which 
waypoint(s) belongs to which application. 

The waypoint calculation is stopped by the application with the message 
„gps__waypoint_stop_req u . 

With the parameter <status> the application can make the waypoint stay 
active even if the system is turned off and is newly initialized. 

Syntax: <msg_id>, <wayp_Jd>, <geom>, <waypoint_data>, <status> 

Defined values: <msg_id>: to be defined 
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<waypjd> waypoint ID set by the application 

<geom>: geometry of the waypoint: 

<geom>=1 : circle 
<geom>=2: rectangle 

<wayppint_data>: waypoint data: 



<status>: 



1 



<geom>=1: ^circle": longitude and latitude of 
circle center, radius, hysteresis, preferred di- 
rection (clockwise, 0 degrees=north), aperture 
angle of preferred direction 

<geom>=2: ^rectangle": longitude and latitude 
of rectangle center, length and width of 
rectangle, hysteresis, preferred direction (0 
degrees=north, clockwise) and aperture angle 
of preferred direction. 

waypoint calculation is active only during 
current operation 

waypoint calculation stays active even if 
the system is turned off and newly 
initialized 



3.2.4.18 Message ' , gps_waypoint_statusJndication , 

Message name: M gps_waypoint_ statusjnd" 
Source: base function waypoint 

Destination: application (or other base function) 
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Description: First this message is used to indicate the arrival of the inner area of the 

waypoint (<status>=1). 

Second it indicates if the car crosses the CENTER line (normal line to 
the preferred direction throught the waypoint center) (<status>=2). With 
this status it is indicated wether the heading of the car is along the pre- 
ferred direction (that is inside the aperture cone of preferred direction) 
(<par_heading>=1 ), or not along the preferred direction direction (that is 
outside the aperture cone of preferred direction) (<par_heading>=0). Al- 
so the current heading <heading> is sent. 

Third the departure of the hysteresis area heading outside the waypoint 
is indicated (<status>=3). 

Fourth in case of backward approximated positions it is indicated that 
the car has arrived at the inner area of the waypoint and has crossed 
the CENTER line (<status>=4). With this status it is indicated wether the 
heading of the car has been inside the aperture cone of the the prefer- 
red direction (<par_heading>=1 ), or outside the aperture cone of the 
preferred direction (<par_heading>=0). Also the heading <heading> at 
that time is sent. 

Fifth in case of backward approximated positions it is indicated that the 
car has arrived at the inner area of the waypoint, has crossed the 
CENTER line and has left the hysteresis area heading outside the way- 
point (<status>=5). With this status it is indicated wether the heading of 
the car has been inside the aperture cone of the the preferred direction 
(<par_heading>=1 ) t or outside the aperture cone of the preferred di- 
rection (<par_heading>=0). Also the heading <heading> at that time is 
sent. 

The Type Of Position (<top(x), top(y)>) of the related GPS position, the 
time (<time>) of this position and the distance (<dist>) of this position to 
the CENTER line (normal to the preferred direction throught the way- 
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point center) is sent with the message. In case of status 4 and 5, the 
TOP (<top(x), top(y)>), the time (<time>), the CENTER line distance 
(<dist>), the parameter <par_heading> and the heading (<heading>) of 
the GPS position, on which the CENTER-message is based, is sent. 



Syntax: 



Defined values: 



<msg_id>. <wayp_id>. <status>, <top(x). top(y)>, <time>. <dist>. 
(if <status>=2, 4. 5: <par_heading>. <heading>) 



<msg_id>: 



to be defined 



<wayp_id>: 



waypoint ID 



<status>: 



1 ..IN": arrival at the inner area of the 
waypoint 



..CENTER": crossing the CENTER line 
(normal line to the preferred direction 
throught the waypoint center) 

..OUT": departure of the hysteresis area 
heading outside the waypoint 

in case of backward approximated positi- 
ons: car has arrived at the inner area of the 
waypoint and has crossed the CENTER line 

in case of backward approximated positi- 
ons: car has arrived at the inner area of the 
waypoint. has crossed the CENTER line and 
has left the hysteresis area heading outside 
the waypoint 



<top(x), top(y)>. Type Of Position of the related GPS position, 



SUBSTITUTE SHEET (RULE 26) 



W ° 97/34431 PCT/EP96/01110 



<dist>: 



<time>: 

"if <status>=2,4,5: 

<par_heading>: 



<heading> 



loo 

top(x) TOP in direction south-north 
top(y) TOP in direction west-east 

distance of the related GPS position to the 
CENTER line (normal line to the preferred directi- 
on throught the waypoint center 

time of the related GPS position 



1 heading of the car is/has been along the 
preferred direction (that is inside the 
aperture cone of the preferred direction) 

0 heading of the car is/has been not along the 
preferred direction (that is outside the 
aperture cone of the preferred direction) 

heading at the related GPS position 



3.2.4.19 Message M gps_waypoint_stop_request" 



Message name: 
Source: 
Destination: 
Description: 



"gps^waypoint^stop^req" 
application (or other base function) 
base function waypoint 

This message is used to stop the waypoint calculation. If the parameter 
<par> has the value 1 , only the waypoint calculation according to the 
waypoint with the waypoint ID <wayp_id> is stopped. If the parameter 
<par> has the value 0 f the waypoint calculation of all waypoints set by 
the application is stopped. 
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Syntax: <msg_id>, <par>, (if <par>= 1 : <wayp_ict>) 

Defined values: <msgjd>: to be defined 

<par> 0 all waypoints set by the application are de 

activated 

1 the waypoint with the waypoint ID 
<wayp_id> is deactivated. 

if <par>=1 ; 

<wayp_id>: waypoint ID 
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3.2.5 Messages related to the Subsystem Access Control 

In this chapter the messages related to the different base functions of the Chipcard interface 
Module (CIM) are decribed. The message transfer between applications and CIMbase 
functions is handled with the following messages: 

related to the CIM base function CIM open application: 

- cim_open_appiication__request 

- cim_open_application_confirmation 

related to the CIM base function CIM command data transfer: 

- cin\_send__data_/equest 

- cim_^send_data_response 

- cim__status_request 

- cim__status_indication 

related to the CIM base function CIM close application: 

- cim_close_application_request 

- cim_close_application_conformation 

An example of message transfers between an application and a CIM base function are de- 
cribed in a time sequence diagram on the following page. 



Illustration 3.2.5-1: Time sequence diagram related to the Subsystem Access Control 
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3.2.5.1 Message ,, cim_open_application_request" 



Message name: "cim_open_application_req'' 



Source: 

Destination: 

Reply: 

Deiscription: 



Syntax: 

Defined values: 



application 



base function CIM open application 



u cim_open_application_con" (open confirmation either positive 
tive) 



or nega- 



This message is used by the application to initiate a communication with 
a chipcard application. 

If the attempt to setup a connection is unsuccessful, the base function 
has to evaluate and/or forward the error causes (e.g. unknown applicati- 
on, no chipcard available). 

With the receipt of this message a logical channel for communication 
between the application and the base function is established. A confir- 
mat,on message containing the logical channel number or the possible 
error cause has to be sent to the requesting application. 

The message contains the message identifier <msg_id> and the appli- 
cation identifier <aid>. 

<msg_Jd>, <aid> 



<msg_id> 



to be defined 



<aid>: 



to be defined 
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3.2.5.2 Message "cim^open_application_confirmation' 



Message name: 
Source: 
Destination: 
Description: 



Syntax: 

Defined values: 



u cim_open_application_con" 

base function CIM open application 

requesting application 

This message is used to confirm that a logical channel is opened for the 
requesting application to send commands or data to the chipcard (with 
li cim_send_data_req ,1 -.messages) . The "cim_open_application_con"- 
message contains a <channeLno>. This <channel_no> is used by fol- 
lowing messages to adress the logical communication channel. 

<msg_id>, <status>, <channeLno> or <cause> 



<msgjd>: 



<status>: 



to be defined 

ACK (to be defined), the next parameter shall be interpre- 
ted as the channeLno 

NAK (to be defined), the next parameter shall be interpre- 
ted as the cause value. 



<cause>: 



to be defined 



<channel no>: 



identifier of the logical communication channel for 
the requested communication 



3.2.5.3 Message "cim_send_data_request" 



Message name: "cim__send_data_req" 
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Source: 

Destination: 

Reply: 

Description: 



Syntax: 



application 



base function CIM command data transfer 

"C»m_send^data_res" (answer of the chipcard) 
"ctm__status_jnd M (an error has occured) 

With this message commands or data to be transmitted to the chipcard 
is sent to the base function. 

The messsage is acknowledged either by the answer of the chipcard 
(positive acknowledge) or by. status message Negative acknowledge). 

The •'cim_send_data_req"-message contains the message identifier 
<ms g _id>, the channel number <channel_no>, the data length 
<data_length> and the data <data>. 

<msg_id>, <channeLno>, <data_length>, <data> 



Defined values: <msg_id> 



to be defined 



<channel_no>: identifier of the logical communication channel for 
the requested communication 

<data_length>: length of the <data> in byte 
<data>: command/data to be sent to the chipcard 

3.2.5.4 Message "cim_ send_data_response" 



Message name: "cim_send_data 



res" 



Source: 



base function CIM command data transfer 
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Destination: 



\oi> 



application 



Description: 



With this message the response data of the chipcard is sent to the re- 
questing application. 



The "cim_send_data_res"-message contains the message identifier 
<msg_id>, the channel number <channeLno>, the data length 
<data_length> and the data <data>. 



Syntax: 



<msg_id>, <channel_no>, <data_length> ( <data> 



Defined values: <msg id> 



to be defined 



<channeLno>: identifier of the logical communication channel for 
the requested communication 

<datajength>: length of the <data> in byte 



<data>: 



command/data to be sent to the chipcard 



3.2.5.5 Message "cim__status_request , 



Message name: "cim_status_req" 



Source: 



application 



Destination: 



base function CIM command data transfer 



Reply: 



"cim status ind" 



Description: 



This message is used to request status of the CIM. 
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The message contains only the message identifier <msgjd>. 



Syntax: 



<msg_id> 



Defined values: <msgMd> 



to be defined 



3.2.5.6 Message "cim_status indication' 



Message name: "cim_status_ind" 



Source: 

Destination: 

Description: 



Syntax: 



base function CIM command data transfer 
application 

This message is used to inform the application about an error or an un- 
expected action occured or about a status change of the equipment 

When receiving the "cim_status_ind"-message the application has to 
decide about the further actions, if an error occures. 

The message contains the message identifier <msg Jd> and the status 
information <status>. 

<msg_id>, <status> 



Defined • Jues: <msg_id> 



to be defined 



<status>: 



status information concerning an error, an unex- 
pected action. or equipment status. 
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3.2.5.7 Message M cim_close_application_request' 



Message name: "cim_close_application_jeq" 



Source: 

Destination: 

Description: 



Syntax: 



application 

base function CIM close application 

This message is used by the application to close the logical communi- 
cation channel between the application and the base function. 

The message contains the message identifier <msg_id> and the chan- 
nel number <channel_no>. 

<msg_id> t <channel no> 



Defined values: <msg_ict> 



to be defined 



<channel_no>: identifier of the logical communication channel for 
the requested communication 



3.2.5.8 Message "cim_close_application_confirmation f 



Message name: 
Source: 
Destination: 
Description: 



,, cim_close_application_con" 



base function cim CIM close application 



application 



This message is used to confirm to the requesting application that the 
logical communication channel between the application and the base 
function has been closed. The communication with the chipcard has be- 
en terminated. 
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The message contains the message identifier <msg_id> and the chan- 
nel number <channel no> 



Syntax: <msg_id>, <channel_no> 

Defined values: <msg_id> to be defined 



<channel_.no>: identifier of the logical communication channel for 
the requested communication 
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3.2.6 Messages related to the Subsystem Input/Output 

in this chapter the messages related to the different Input/Output (I/O) base functions are 
decribed. The message transfer between applications and I/O base functions is handled with 
the following messages: 

related to I/O base function io display information: 

- io_display_information_request 

- io_display_information„confirmation 

- io_display_information_acknowledgement 

- io_display_information_interruption 

- io_display_information_rejection 

- io_display_information_finish_request 

- io_display_information_finish_acknovyledge 

- io_display_type_request 

- io_display_Jype_result 

related to I/O base function io enter data: 

- io_input_device_request 

- io_input_device_acknowledge 

- io_input_device_reject - 

- io_enter_data_request 

- io_enter_data_confirmation 

- io_enter_data_result 

- io_enter_data_acknowledge 

- io_enter_data_reject 

* io__input_device_Jype_request 

- io_inp ; , _device__type_jesult 

Some examples of message transfers related to the Input/Outpout-Device base functions 
are decribed in a flow chart, that illustrates the general interworking, and time sequence dia- 
grams on the following pages. 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT7EP96/01110 



III 



Illustration 3.2.6-1: Phase diagram related to the I/O base function display information 



Illustration 3.2.6-2: Time sequence diagram related to the I/O base function display informa- 
tion 



Illustration 3.2.6-3: Time sequence diagram related to the I/O base function display inforrna- 

. tion 



Illustration 3.2.6-4: Time sequence diagram related to the I/O base function display informa- 
tion 



Illustration 3.2.6-5: Time sequence diagram related to the I/O base function display informa- 
tion 



Illustration 3.2.6-6: Time sequence diagram related to the I/O base function enter 
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Illustration 3.2.6-7: Time sequence diagram related to the I/O base Junction enter data 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



It3 

3.2.6.1 Message „io_display_information_request' 



Message name: „io_display_information_req 



Source: 

Destination: 

Reply: 



Description: 



application or any other base function 
base function io display information 

,.io_displayjnformation_con" (request confirmation) 
,.io_display_lnformation_ack" (request acknowledgement) 
Jo_display_information_int" (request interruption) 
Jo_display_information_rej" (request rejection) 

This message ist used by applications and base functions to display 
data on the Input/Output-Device. The request contains information to be 
displayed as well as the controlling information of the display job. 

If an application sends a display information request to a display unit 
which is at requesting time not operational or to which the application 
doesen't have an access right, the base function rejects the request. 

If the display is not busy with another job the display information request 
is accepted and an J'o^display_information_confirmation"-message is 
send to the originator of the request. When the information is displayed 
over a time period of <t_dur> an 

„io_display_information_acknowledgement"-message is send. 

If an io_display_information_request of another application with a higher 
request priority accures during the time period <t_dur> the actually dis- 
played information is interrupted and an 

io_display_information_interruption message is send to the originator of 
the related application. 
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If the io_display_information_request has a lower or equal request priori- 
ty than the currently displayed information, the request is put in a queue. 
If the duration time in the queue is longer than a predefined value, the 
io_display_information_request is rejected. 

Syntax: <msg_id>, <ioJd>, <info_typ>, <t_dur>, <t_queue>, <session_id>, 

<finish_typ>, <infoJength>, <info>, <adj>, <format>, <font>, <size> 

Defined values: <msg_id> to be defined 

<io_id> identifier of the Input/Output-Device where the in- 

formation is to be displayed 
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<info_typ> 



<t_dur> 

<t_queue> 
<session id> 



<finish_typ> 



<info_iength> 

<info> 

<adj> 



type of information 
possible values are: 
b - bitmap 
c - character 

p - predefined message/symbol 

minimum duration in seconds the information has to 

be displayed 

maximum time in queue until display reject 
id of a display/input session with a number of infor- 
mations to be displayed together and input data to 
be entered by the user. This display/input actions 
belong together and shall not be disturbed by a 
display request of an equal priority, 
type to finish the display of an information 
possible values are 
c - continued display of information; 

when the display duration <t_dur> is excee- 
ded the display status is set to accessible" 
but the display holds the old information until 
a new information is to be displayed 
a - to be finished only by command 

io_displayJnformation_finish_request of the 
originating application or base function 
length of the information in byte 
information to be displayed 
adjustment information 
possible values are: 
s - standard 
v - centered vertically 
h - centered horizontally 
x - special formatting of information 



if <adj> = „x" then following additional parameters 
are included in the parameter structure: 
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<format> formating information 

possible values are: 
b - bold 
i - italic 
u - underlined 
<font> character font 

<size> character size 

possible values in pt 
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3.2.6.2 Message ,,io_displayJnformation_rejecr 



Message name: Jo_display_information_rej" 



Source: 



base function io display information 



Destination: 



requesting application or base function 



Reply: 



none 



Description: 



An io_display_information_reject message is send for two reasons: 

- access to base function not possible 

- Lqueue exceeded 

If an application or a base function sends a display information request 
to a display unit <io_id> which is at requesting time not operational or to 
which the application has no access right, the base function sends the 
io„displayjnformation_reject message to the requesting application or 
base function. 

If the io_display_information_request has a lower or equal request priori- 
ty than a currently displayed information, the request is put in a queue. If 
the waiting time in the queue is longer than the value <t_queue> the re- 
quest is rejected. 



Syntax: 

Defined values 



<msg_id>, <rej_stat> 



<msg_Jd> 
<rej_stat> 



to be defined 

reason for reject 

possible values are: 

na - access not allowed 

no - display unit not operational 

te - time exceeded <t_queue) 
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3.2.6.3 Message „io_displayjnformation_confirmation* 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



Syntax: 

Defined values 



Jo_displayjnformation_con" 



base function io display information 



requesting application or base function 



none 



In case of the display operational and the requesting application or base 
function has a access right the io_display_information_request is accep- 
ted and an io_display_information_confirmation message is send to the 
originator of the request. 

<msg_id>, <con_status> 



<msg_id> 
<con status> 



to be defined 

status of confirmation 

possible values are: 

d - information displayed 

q - information request in queue 



3.2.6.4 Message Jo_displayJnformation_interruption 4 



Message name: Jo_displayJnformation_int" 



Source: 



base function io display information 
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Destination: 

Reply: 

Description: 



Syntax: 

Defined values 



requesting application or base function 



none 



If an io_display_information_request of another application with a higher 
request priority accures during the time period <t_dur> the actually dis- 
played information is interrupted and an 

io_display_informationjnterruption message is send to the originator of 
the interrupted application display. 

<msg_id>, <int_/eason> 



<msg_id> 
<int_reason> 



to be defined 

reason of the interruption 

possible values are: 

nr - new request of an application or base function 
with higher request-priority 
priority of an io_displayjnformation_request 
in the queue is higher than the priority of the 
actually displayed information. 
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3.2.6.5 Message „io_display_information_acknowledge" 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



Syntax: 

Defined values 



Jo_display_jnformation_ack 1 ' 



base function io display information 



requesting application or base function 



none 



When the information is displayed over a time period of <t_dur> this 
message is send to the originator of the request. With this message the 
display job for the requested information to be displayed is finished. 

If <finish_typ> = >t c" (parameter of io_display_information_request) the 
status of the display is set to ^accessible". With any new 
io_display_information_request the actual display content is deleted. 

,ln case of <finish_typ> = , f a u (parameter of 

io_display_information_request) the status of the display stays „busy" 
until the originator of the displayed message breaks displaying informa- 
tion with an io_display_information_finish_request. 

<msg_id> 



<msg_id> 



to be defined 



3.2.6.6 Message „io_displayJnformation_finish_request 4< 



Message name: „io_displayJnformation_finish_req" 



Source: 



requesting application or base function 
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Destination: 

Reply: 

Description: 



Syntax: . 
Defined values 



base function io display information 

Jo_display_information_finish_ack" 

With this message the following actions are initiated: 

When the io_display_information_request is already finished the dis- 
played information is cleared on the Input/Output-Device. 

If the io_display_information_request is still in the queue waiting for dis- 
play access it is now dropped from the queue (application initiated). 

If the io_display_information_request to be finished is part of a number 
of interdependent io_display_information_requests (parameter 
<session_id> in io_display_information_request), with the parameter 
<del_ses S ion> it is defined what action takes place with the other 
io_display_information_request of this session. 

<msg_id>, <io_id>, <del sessibn> 



<msg id> 
<io id> 



<del_session> 



to be defined 

identifier of the Input/Output-Device the information 
is to be displayed 

action for other requests with equal session id 

possible values are: 

n - no finish of the other 

io_display_information_requests of the same 
session; only identified 

io_display_information_request is dropped 
from the queue or cleared from the display, 
y - all io_display_information_requests of the 

same session and originator are dropped from 
the queue or cleared from the display. 
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3.2.6.7 Message „io_display_information_finish_acknowledge" 



Message name: „io_display_information_finish_ack" 



Source: 



base function io display information 



Destination: 



requesting application or base function 



Reply: 



none 



Description: 



When the actions requested with io_display_information_finish_req are 
performed, the io_display_information__finish_ack message is send to 
the originator of the request. 



Syntax: 

Defined values 



<msg_id> 



<msg id> 



to be defined 
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3.2.6.8 Message „io_display_type_request" 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



Syntax: 

Defined values 



Jo_display_type_req" 



requesting application or base function 



base function io display information 



Jo^display^type^res" 



With this message the application or base function requests the use of 
the Input/Output-Device identified with <ioJd>. With the response mes- 
sage io_display_Jype_res the application is informed about her access 
right to the mentioned Input/Output-Device. 



<msg id>. <io_id> 

<msg_id> 
<io id> 



to be defined 

identifier of the Input/Output-Device the information 
is to be displayed 



3.2.6.9 Message „io_display_type_resuir 



Message name: Jo_display_type_res" 



Source: 



Destination: 



Reply: 



base function io display information 



requesting application or base function 



none 
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Description: 



12V 

With this message the base function informs the requesting application 
or base function about her access right to the related Input/Output- 
Device. 



Syntax: 



<xnsgjd>, <access stat> 



Defined values 



<msg_id> 
<access stat> 



to be defined 

access status for the Input/Output-Device 
possible values are: 
n - no access 

access allowed; requesting application only 
access allowed; common used Input/Output- 
Device (all applications) 
access allowed; used by multiple applications 



y 

c 
m 



3.2.6.10 Message f ,io_input_device_request 4 



Message name: Jo_input_device_recf 



Source: 



requesting application or base function 



Destination: 



base function io enter data 



Reply: 



Description: 



Jo_input_device_ack" 
Jo_input_device_rej" 



When an application or a base function want to request for input data, 
first it has to be checked whether the input device is accessible or in use 
for an other application. An io Jnput_device_req is send to the input de- 



vice. 



If the input device is accessible the input device is attached to and an 
Jo_input_device_ack** message is sent to the requesting application. 
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Syntax: 

Defined values 



The input device is blocked for requests of other applications. Its status 
is set to „busy". 

If the input device is .busy" an JoJnpuLdevice.rej" is sent ot the re- 
questing application. The reason for rejection is although be sent as 
status parameter. The status can be „busy" or „access_not_allowed". 

An application detaches from an input device also with an 
io_input_device_req-message (<attach>*=no). 

<msgjd>, <in_devjd>, <attach> 



<msg_id> 
<in_jjev_jd> 

<attach> 



to be defined 

identifier of the input device selected from which 
data should be entered 

distrngish between attach to and detach from the 

input device 

possible values are: 

yes - attach to input device 

no- detach from input device 



3.2.6.11 Message ,,ioJnput_device_acknowledge' 



Message name: JoJnput_device_ack" 



Source: . 

Destination: 
Reply: 



base function io enter data 

requesting application or base 
none 



Description: 



This message is the response of an io_inp U t_device_request. In case 
that the input device is accessible and the requesting application has the 
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right to access to the input device the input device is attached to the re- 
questing application. The status of the input device is set to „busy" and 
the io_jnput_device__ack-message is sent to the requesting application. 



Syntax: 

Defined values 



<msg_id> 



<msg__id> 



to be defined 



3.2.6.1 2 Message „io_input_device_rejecr 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



l ,io_input__deyice_re] M 



base function io enter data 



requesting application or base function 



none 



This message is the response of an io_input_device_request. In case 
that the input device is t ,busy" or the requesting application does not ha- 
ve the right to access to the input device the request is rejected. An 
io_input_device_rej-message is sent to the requesting application or ba- 
se function. The message contains a parameter „status" with an indica- 
tion of the reason of rejection. 



Syntax: 

Defined values 



<msgjd>, <status> 

<msg_jd> 
<status> 



to be defined 
reason of rejection 
possible. values are: 

busy - device is currently attached to an other 
application 
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na - access to the selected input device, is not al- 
lowed 

no- input device is currently not available 
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3.2.6.13 Message „io_enter__data_request" 

Message name: M io_enter_data_req" 

Source: requesting application or base function 

Destination: base function io enter data 

Reply: „io_enter_data_con" 
„io_enter_data_res" 
Jo_enter_data_rej" 

Description: When an application or a base function needs input data from the user it 

has to perform the following actions: 

a. check whether the input device is accessible an at- 
. tach (io_input_device_req) 

b. display an „enter data message" on the In- 
put/Output-Device (io_displayJnformation_req) 

c. generate an „enter data request" to the In- 
put/Output-Device (io_enter_data_req) 

The first action to be performed is to attach to an input device . Then as 
second action the user has to be told that an application needs input 
data. This is be done perhaps with an acustic signal (pieper or voice re- 
quest) and with a display information that describes the expected user 
action. 

When „enter data message" is displayed (io_display_data_con) the 
application requests the input data. An io_enter_data_req is sent to the 
selected input device. The input device responds with an 
io_enter_data_con-message. 

With the acceptance of the io_enter_jjata_req (io__data_req_con) a 
watchdog is activated in the interpreter/input device. This is for con- 
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trolling the user enters inputs data within a maximum duration time. The 
timer parameter for the watchdog is part of the io_enter_data_req 
«timer>). if the user pushes a data or event-key the watchdog is always 
restarted with the content of <timer>. If the user does not push any key 
wrthin the time period <timer> the watchdog rejects the data request 
with an io_enter__data_rej-message. 

With the parameter <type> of the io_enter_data_req it is distinquished 
whether the application expects for response a single charcter or a cha- 
racter stnng. | n case of the application expects a character string all 
character inputs are to be collected in the interpreter/input device until 
the user pushes an event-key. When the user pushes the event-key 
..enter the collected data are send to the requesting application with the 
message io_enter_data_res. When the user pushes the event-key 
..cancel" the collected data are deleted and an io_enter_data_rej- 
message is sent to the application. 

In case of the application expects a single character the input device 
sends each entered character with a respective io_enter_data_res- 
message to the application. The application now can check the cha- 
racter and decide about sending a new Jnput-data" message (i e the 
new possible character to enter a town name for third possition depen- 
dent on the first two characters the user had entered). This is repeated 
until the event-key „enter" is pushed. 

If another event-key .ike ..menue" is entered the interpreter/input device 
sends an io_enter_dataJnd-message to the requesting application The 
appl.cat.on decides about the following actions. If there is currently no 
..enter data request" the event-keys are controled by a special- 
application which interprets the user action and initiates for application 
actions. 

In general all user entered characters are to be displayed on a corre- 
spondent display <i 0 _id>. Dependent on the Input/Output-Device it is 
poss,ble that the ..enter data message" together with the entered data 
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are displayed on the Input/Output-Device or that the „io_enter_data"- 
message is deleted with the first entered character. For special purpo- 
ses i. e. enter of pin this feature muB be inhibited <displ_ch>. In this ca- 
se a special character like „* M is to be displayed on the Input/Output- 
Device. 

When an user has entered the requested data he terminates his input 
action with the event-key ..enter. When the data entered are sent to the 
requesting application the „enter data request" is finished by sending an 
io_enter_data_ack-message. 



Syntax: 



<msg_id>, <in_dev_id>, <io_id>, <type>, <timer>, <displ_char>. 
<session_Jd>, <finish_typ>, <adj>, <format>, <font> ( <size> 



Defined values 



<msg id> 
<in_dev_Jd> 

<io_id> 

<type> 



<timer> 
<dispi_char> 



<session id> 



to be defined 

identifier of the input device selected from which 
data should be entered 

identifier of the Input/Output-Device the information 
is to be displayed 

identifier for the kind of expected input data 
possible values are: 
c - single character expected 
s - string expected 
timer constant for watchdog (in seconds) 
determines whether the entered character is dis- 
played on the Input/Output-Device 
possible values are: 

yes - entered character is displayed on In- 
put/Output-Device (default) 
no- entered character is not to be displayed on 
Input/Output-Device; in exchange character 
„*" is to be displayed 
id of a display/input session with a number of infor- 
mations to be displayed together and input data to 
be entered by the user. This display/input actions 
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<finish_typ> 



<adj> 
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belong together and shall not be disturbed by a 

display request of an equal priority. 

type to finish the display of an information 

possible values are 

a - to be finished only by command 

io_displayJnformation_finish_request of the 
application or base function the 

io_display_infprmation_request is owned by. 
adjustment entered data 
possible values are: 
s - standard 
v - centered vertically 
h - centered horizontally 
x - special formatting of information 



if <adj> = „x" then following additional parameters 
are included in the parameter structure: 



<format> 



<rfont> 



formating information 
possible values are: 
b - bold 
i - italic 
u - underlined 
character font 
character size 
possible values in pt 



3-2.6. 1 4 Message „io_enter_data_conf irmation ' 

Message name: Jo_enter_data_con tt 
Source: base function io enter data 
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Destination: 

Reply: 

Description: 



requesting application or base function 



Syntax: 

Defined values 



none 



When an application requests for input data an io_enter_data_req- 
message is sent to the selected input device. In case of confirmation the 
input device responds to the application with an io_enter_data_con- 
message. The input device is now ready to get input data from the user. 
Also the watchdog function for controlling the duration between the 
single input action is activated. 

<msg_id> 



<msg_id> 



to be defined 



3.2.6.15 Message „io_enter_data_acknowledge" 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



Syntax: 



,io_enter data ack" 



base function io enter data 



requesting application or base function 



none 



When an user has entered the requested data he terminates his input 
action with the event-key „entef . When the data entered are sent to the 
requesting application the „enter data request" is finished by sending an 
io_enter_data_ack-message. 

<msg_id> 
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Defined values <msg_id> 



to be defined 



3.2.6.16 Message „io_enter_data_result" 



Message name: „io_enter_data res" 



Source: 



base function io enter data 



Destination: 



requesting application or base function 



Reply: 



none 



Description: 



With the parameter <type> of the io_enter_data_req it is distinguished 
whether the application expects for response a single character or a 
character string. In case of the application expects a character string all 
character inputs are to be collected in the interpreter/input device until 
the user pushes an event-key. When the user pushes the event-key 
„enter the collected data are send to the requesting application with the 
message io_enter_data_res. 

In case of the application expects a single character the input device 
sends each entered character with a respective io_enter_data_res- 
message to the application. The application now can check the cha- 
racter and decide about sending a new Jnput-data" message (i. e. the 
new possible character to enter a town name for third possition depen- 
dent on the first two characters the user had entered). This is repeated 
until the event-key „enter" is pushed. 



Syntax: 

Defined values 



<msgjd>, <data_length>, <data> 



<msg_id> 



to be defined 
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<data_length> length of the entered input data 
<data> user input data 



3.2.6.17 Message „io_enter_data_rejecr 



Message name: 

Source: 

Destination: 

Reply: 

Description: 



„io_enter__data_rej" 



base function io enter data 



requesting application or base function 



none 



To get user input data an io_enter_data_request is sent to the input de- 
vice. An iq_enter_data_rej-message is sent from the base function to 
the requesting application in following described cases. 



If an application wants to access to an input device and this device is 
not operational or the application does not have the right to access to 
that input device (currently or permanently) an io_enter_data_/ej- 
message is sent. The reason for rejection is contained in that message 
<con_status>. If an error occures during the time input actions take 
place although an io_enter_data_rej-message is sent. 

If the time between two input actions (L e. the push of an data-key) 
exceeds a limit a watchdog functionality interrupts the 
io„enter_data_request and sends an io_enter_data_rej-message. 

If an user interrupts entering data by pushing the event-key <cancel> an 
io_enter_data_rej-message is sent to the requesting application. 



Syntax: 



<msgjd>. <rej_status> 
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Defined values 



<msgjd> 
<reLstatus> 



to be defined 

reason for rejection the io_enter_data_request 

possible values are: 

c - cancel (event-key) user initiated 

t - timeout (duration time exceeded) 

na - no access allowed 

no- not operational 



3.2.6.18 Message ,,io_enter_data_indicatfon 4 



Message name: Jo_enter_data_ind" 



Source: 



base function io enter data 



Destination: 



requesting application or base function 



Reply: 



none 



Description: 



If the user pushes an event-key like „menue" the interpreter/input device 
sends an io_enter_data_ind-message to the requesting application. The 
application decides about the following actions. If there is currently no 
„enter data request" to be worked out the event-keys are controlled by a 
special-application which interprets the user action and initiates for 
application actions. 



Syntax: 

Defined values 



<msgjd>, <key__code>, <req_status> 



<msg_id> 
<key_code> 



to be defined 

identifier for the key the user had entered 

possible values are: 

menue - key for entering a menue 
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<req_status> 



13b 
up- cursor 
down - cursor 
help - help key 
access-status of input device 
possible values are: 
a - accessible 
b - busy 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCTYEP96/01110 



3.2.6.19 Message „io_input_device_type_request < 



Message name: Jo_input_device_type_req H 



Source: 
Destination: 
Reply: 
Description: 



Syntax: 

Defined values 



requesting application or base function 



base function io enter data 



Jo_input_device_type_ res" 

With this message the application or base function requests the use of 
the input device identified with <in_devjd>. With the response message 
io_input_device_type_res the application is informed about her access 
right to the mentioned input device. 

<msg^_id>, <in_dev_id> 



<msg_id> 
<in dev id> 



to be defined 

identifier of the input device selected from which 
data should be entered 



3.2.6.20 Message „io_input_device_type_result" 



Message name: .,ioJnput_device_type_res ,( 



Source: 



base function io enter data 



Destination: 



requesting application or base function 



Reply: 



none 
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Description: 
Syntax: 

Defined values 



136 

With this message the base function informs the requesting application 
or base function about her access right to the mentioned input device. 

<msg_id>, <access stat> 



<msg_jd> 
<access stat> 



to be defined 

access status for the input device 
possible values are: 
n - no access 

y - access allowed; requesting application only 
c - access allowed; common used input device 

(all applications) 
m - access allowed; used by multiple applications 
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4 Standard Communications Interface 



The basic device is designed to allow integration of Traffic Telematics applications and ap- 
propriate Input/Output-Devices, but also to provide a Standard Communications Interface 
(SCI) for connecting external devices. This is useful for extending the basic device with 
applications currently available or for adding new applications or devices as they become 
available in the future. 

An external device may be a further Traffic Telematics application, another Input/Output- 
Device, a facsimile terminal, a PC or an adaptable car bus system, e.g. the CAN bus. 

Some PC based applications can use the direct communication path provided by the GSM 
module. Other PC based applications may be connected to allow access to the internal units 
of the basic device: for example to start and monitor diagnostic functions or to read the error 
log (by service staff only). 

It is the aim to offer a manufacturer-independent access to the basic device. For this reason, 
the Standard Communications Interface is a universal serial bus, which allows connection of 
several external devices. It is proposed to use an RS485 bus for this purpose. 

The basic device includes the Standard Communications Interface module (SCI module). 
This is used to connect the external bus to the API. 



4.1 The SCI module and the communication paths 

All external devices have a single.common access to the API via the SCI module, which re- 
presents all external devices at the API. For this reason the SCI module manages the con- 
nections between the external devices and the integrated applications or base functions. 

In principle, there are two different kinds of access from an external device: Access via the 
API and direct access. 
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Access via API is used for the normal communications between the external devices and 
the applications or base functions within the basic device. 

Direct access is used for transparent GSM data connection between one external device 
and an external user, e.g. for PC or facsimile applications. Direct access is provided only via 
the SCI. 



4.2 Tasks of the SCI module 

It is the task of the SCI module to provide either the pure API connection profile or the direct 
access prof.le, depending on the requirements of the applications (see Picture 4 2-1) For 
this purpose there is a switch to control the connection path. The swrtch position in the pictu- 
re .s for normal connection to the API. Another switch position is used to enable a protocol to 
ensure data integrity providing protection against transmission disturbances on the external 
bus. Switching to the third position results in a ..direct access" via the communication module 
and the API to the GSM radio path. 



Illustration 4.2-1: Standard Communications Interface (SCI) 



The SCI module has the task of managing the switches as requested by the applications. 

Another task of the SCI module is to take part in the priority management. If a command is 
sent from an external device to a base function and is rejected by the concerning priority 
management, it is the task of the SCI module to accept the reject message and to react ac- 
cordingly. In the other direction, if more than one application or base function attempts ac- 
cess concurrently e.g. to an external Input/Output-Device, it is the job of the SCI module to 
resolve the conflict. 
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5 Annex 

5.1 Annex 1: Extract of the GSM TS 02.07: 



Annex A (normative): Automatic calling repeat call attempt restrictions. 

Call set up attempts referred to in this annex are assumed to be initiated from peripheral 
equipment or automatically from the MT itself. 

A repeat call attempt may be made when a call attempt is unsuccessful for the reasons listed 
below (as defined in GSM 04.08). 
These reasons are classified in three major categories: 
1- "Busy destination": 

Cause number 17 User busy 

2. "Unobtainable destination - temporary": 

Cause number 1 Unassigned (unallocated) number 

3 No route to destination 

22 Number changed 

28 Invalid number format (uncomplete number) 

38 Network out of order. 

18 No user responding 

19 User alerting, no answer 
27 Destination out of order 

34 No circuit/channel available 

41 Temporary failure 

42 Switching Equipment congestion 

44 Requested circuit/channel not available 

47 Resources unavailable, unspecified 

3. "Unobtainable destination - permanent/long term* 1 : 
Cause number 

NOTE: Optionally, it is allowed to implement cause number 27 in Category 3, instead of 
Category 2. as this is desirable already in Phase 1. 
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The table below describes a repeat call restriction pattern to any B number. This pattern de- 
fines a maximum number (n) of call repeat attempts; when this number n is reached, the as- 
sociated B number shall be blacklisted by the MT until a manual re-set at the MT is perfor- 
med in respect of that B number. When a repeat attempt to anyone B number fails, or is 
blacklisted, this does not prevent calls being made to other B numbers. 

For the categories 1 and 2 above, n shall be 10; for category 3, n shall be 1 . 



Call attempt Minimum duration between call at- 

tempts 

Initial call attempt 

1 st repeat attempt 5 sec 

2nd repeat attempt 1 min 

3rd repeat attempt 1 min 

4th repeat attempt 1 min 

5th repeat attempt 3 min 

nth repeat attempt 3 min 



The number of B numbers that can be held in the blacklist is at the manufacturers discretion 
but there shall be at least 8. However, when the blacklist is full the MT shall prohibit further 
automatic call attempts to any one number until the blacklist is manually cleared at the MT in 
respect of one or more B numbers. 

When automatic calling apparatus is connected to an MT1 or MT2, or where an MTO is 
capable of auto-calling, then the MT shall process the call requests in accordance with the 
sequence of repeat attempts defined above, i.e. requests for repeat attempts with less than 
the minimum allowed duration between them shall be rejected by the MT. 
A successful call attempt to a number which has been subject to the call restrictions shown 
above (i.e. an unsuccessful call set up attempt has previously occured) shall reset the 
"counter" for that number. 

The "counter" for an unsuccessfully attempted B number shall be maintained in 24 hours or 
until the MT is switched off. 

The automatic calling repeat call attempt restrictions apply to speech and data services. 
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NOTE: The restrictions only apply to unsuccessful Call Control activity, not to Radio Re- 
source Management or to Mobility Management, so multiple attempts at radio channel ac- 
cess are not limited by this mechanism. 
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Release Causes defined in GSM TS 04.08 see table 5.1-1 

All other values in the range 0 to 31 shall be treated as cause 31 . 
All other values in the range 32 to 47 shall be treated as cause 47. 
All other values in the range 48 to 63 shall be treated as cause 63. 
All other values in the range 64 to 79 shall be treated as cause 79. 
All other values in the range 80 to 95 shall be treated as cause 95. 
All other values in the range 96 to 111 shall be treated as cause 111. 
All other values in the range 112 to 127 shall be treated as cause 127. 
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Release Causes defined in GSM Recommendation 07.07 see table 5.1-2 

other values between 1 28 and 255 are reserved 
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Additional recommended causes see table 5.1-3 
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5.2 Annex 2: Indirect/Direct Access to the AT Command Set 

The AT commands which are listed in table 5.2-1 are extracted of the GSM 07 07 AT 
command set for GSM Mobile Equipment (ME)" [2). They are used in the Subsystem Com- 
munication. 
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5.3 Annex 3: Message Sequence and Service Primitives of the TASP4- 
Protocol 

The message sequence and the Service Primitives of the TASP4-Protokolls, presented in 
chapter 2.2.1-5, are described below. 



Message Sequence see illustration 2.2,1-5 



Illustration 2.2.1-5: Framework of the TASP4 level 

Begin Flag 

The Begin-Flag marks the beginning of the frame. It consists of the bit sequence 01111110. 
There will be no End-Flag. The end of the message will be indicated by means of a length 
indicator. 

The Begin Flag is not normally part of level 4; however, it makes possible the line oriented 
transfer on routes without a leve 2 protocol (transparent data channel). 

LAPB address field not necessary 

Since only one user is to have access to the transport protocol, no address field is 
necessary. The task of the address field in the LAPB protocol, to distinguish between com- 
mand and response, will be fulfilled by the C/R-Bit in the Length Indicator Field. The multi- 
plexing of several connections can be undertaken by the application that manages an ad- 
dress field within the data field (from the point of view of the TASP4 level). 
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Control Field 



The Control Field consists of an octet. There are three diffierent formats S- and U- for- 

mat) (see illustration 2.2.1-6). 



Illustration 2.2.1-6: Control Field 
N(S) Transmitter send sequence number 
N(R) Transmitter receive sequence number 
I Information frame 
S Supervisory frames 
U Unnumbered frames 

P/F Poll bit when issued as a command, Final bit when issued as a response 

The exact bit coding is shown in illustration 2.2.1.-7; it corresponds to the LAPB format: 

Illustration 2.2.1-7: Coding according to the LAPB format 

I Information 
RR Receive Ready 
RNR Receive Not Ready 
REJ Reject 

SABM Set Asynchronous Balanced Mode 

DM Disconnect Mode 

Ul Unnumbered Information 

DISC Disconnect 

UA Unnumbered Acknowledge 

N(S) Transmitter send sequence number 

N(R) Transmitter receive sequence number 

P/F Poll bit when issued as a command, when issued as a response 
P Poll bit 
F Final bit 



The protocol for the use of the control field parameter is described in the CCITT- 
Recommendation X.25 [7] or Q.921 . 
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Definition of Parameters 



window size 



3 



number of repetitions before an error message will be sent to a 
superior level = 6 repetition timer = to be defined, depending on 
Bearer Service 



Length Indicator Field 

The Length Indicator Field consists of the length indicator, the C/R-Bit, the M-Bit and the EL- 
Bit (see illustration 2.2.1-8). 

Illustration 2.2.1-8: Length Indicator Field 

L Length indicator 

C/R Command/Response-Bit 



L Length Indicator 

In Ul and I frames the length indicator defines the length of the data field in octet. If the 
length indicator is 5 bit (see illustration 2.2.1-8), the length of the data field is between 0 and 
31 octet. If the data field is larger than 31 octet, the length indicator field will be enlarged 
(see EL bit). 

In the case of messages that contain no information field, the length indicator is 0. 
C/R Command/Response-Bit 

The C/R-Bit is set at 0 if a command is sent; it is set at 1 if a response is sent. 
M More Data-Bit 

The function of the more data bit is the segmentation of messages. 

The M-Bit set at 1 indicates that this is a part (a segment) of a long ceherent message. 



M 



More Data Bit 



EL 



Length indicator field extension bit 
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If, on the other hand, the M-Bit is set at 0 and the M-Bit of the preceding message was 0 as 
well, the information field contains the complete message. 

If the M-Bit is set at 0 and the M-Bit of the preceding message is 1, the information field 
contains the last part (segment) of a longer message. 

The M-Bit is relevant only as far as l-frames are concerned, in the case of a., other frames 
the M-Bit is set at 0. 



EL Length indicator field extension bit 

The function of the EL-Bit is to extent the length indicator. If it is set at 0. this indicates the 
last octet of the length indicator. If it is set at 1. a further octet follows that belongs to the 
length indicator field. 

If a data field is between 0 and 31 octet in length, the fo.lowing coding of the length field 
(illustration 2.2.1-9) is sufficient. The EL-Bit is here set at 0. 



Illustration 2.2.1-9: Length indicator field for a data field between 0 and 31 octet in length 

If the data field is larger than 31 octet, the length indicator field can be enlarged with the help 
of the EL-Bit (see illustration 2.2.1-10). The length of the data field can then be between 16 
and 4095 octets. 



Illustration 2.2.1-10: Enlarged length indicator field 



Information field 

The information field contains the data of the application level. It can be as long as 4095 
octet. a 



Frame Check Sequence field 

The Frame Check Sequence field is two octet in length. 
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The generator polynom is x 16 + x 12 + x 5 + 1 . 



Service Primitives 

The Service Primitives between the superior level and the transport level are: 

T-Connect- Request 
T-Connect - Indication 
T-Connect - Response 
T-Connect - Confirm 
T-Data - Request 
T-Data - Indication 
T-Unitdata - Request 
T-Unitdata - Indication 
T-Disconnect - Request 
T-Disconnect - Indication 
T-Disconnect - Confirm 
T-Error - Indication 

The Service Primitives between the transport level and the inferior level (Network Layer) are: 

N-Data - Request 
N-Data - Indication 
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5.4 Annex 4: Defined values for super frame structure 

The following values are defined for the super frame structure. A detailed specification of 
these values is for further study. 



<SRC> and <DEST> 3 : 



0x0000 ... OxOFFF 



base functions: 



0x1000 ... 0x1 OFF 
0x1100 ... 0x11 FF 
0x1200 ... 0x12FF 
0x1300 ... 0x1 3FF 
0x1400 ... 0x14FF 

0x1500 ... 0x1 5FF 



gsm_. 

gsm_ 

gps_ 

gps_ 

gps_ 

cim_ 

cim_ 

cim_ 

io_ 

io_ 

io_ 

applications for dynamic route guidance 
applications for floating car data acquisition 
applications for fleet management 
applications for traffic information 
applications for emergency break down 
services 

applications for vehicle theft protection 



Note: Some addresses must be reserved for further chipcard readers 
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0x1600 ... 0x16FF 
0x1700 ... OxFFFF 



applications for automatic tolling 

reserved 



<TRANS_NO>: modulo 256 



<PRIO>: 1 
2 



highest priority level 



n lowest priority level 

(„n u depends on the definition in the appropriate chapter above) 
<TIME>: mm dd hh mm ss: 



mm: 


month: 


0...12 


dd: 


day 


0...31 


hh: 


hours: 


0...23 


mm: . 


minutes 


0...59 


ss: 


seconds 


0...59 



The value range for the applications might be used as values for the asi, too. 
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Abbrev iations 




A OT 

Arl 


... 

Application Programming Interface 


A CT 
Aol 


Application Service Identifier 


DC 


Bearer Service 


CIM 


Chipcard Interface Module 


CLJ 


Calling Line Identity 


CLIP 


Calling Line Identity Presentation 


CLJK 


Calling Line Identity Restriction 


CPU 


Central Processing Unit 


CRC 


Cyclic Redundancy Check 


CST 


Communications Service Table 




Differential Global Positioning System 


DISC 


Disconnect-Message 


EPE 


Estimated Position Error 


ETSI 


European Telecommunications Standards Institute 


GPS 


Global Positioning System 


GNSS 


Global Navigation Satellite System 


GPRS 


General Packet Radio Service 


GSM 


Global System for Mobile Communications 


HDLC 


High-level Data Link Control 


IntraGSM 


International Traffic Global System for Mobile Communications 


I/O 


Input/Output 


LAPB 


Line Access Procedure on the B-channel 


MCC 


Mobile Country Code 


MNL 


Mobile Network Code 


MO 


Mobile Originated 


MOL 


Mobile Originated Call 


M 1 


Mobile Terminated 


MIC 


Mobile Terminated Call 


Obi 


Open Systems Interconnection 




Packet Data on Signalling Channels Service 


PI \yf\T 


Public Land Mobile Network 


O KID 

KINK 


Receive Not Ready 


K 1 CM 


Radio Technical Commission for Maritime Services 




Set Asynchronous Balanced Mode 


SCI 


standard Communications Interface 


SMS 


Short Message Service 


SMS-MO 


Short Message Service - Mobile Originated 


SMS-MT 


Short Message Service - Mobile Terminated 


ss 


Supplementary Service 


TASP4 


Telematic Application Security Protocol 


TCP 


Transport Communications Protocol 


TOP 


Type of Position 


TS 


Teleservice 


VT 


Traffic Telematics (Verkehrstelematik) 
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Traffic Telematics System 
Claims: 

1 . Traffic telematics system 

characterized in that the traffic telematics system contains one or more subsystems 

2. Traffic telematics system according to claim 1 f 

characterized in that the system contains at least one communication subsystem. 

3. Traffic telematics system according to claim 1 or 2, 

characterized in that the system contains at least one navigation subsystem. 

4. Method for use in a traffic telematics system, 

characterized in that base functions of a base system are used to run and/or control 
subfunctions of one or more subsystems. 
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ne 



l|3 9 



Anwendunc 1 2 



n <^~) Anwendungsentwickl 
' Service Betreiber 



Endgerate-Plattf orm 
(Software) 



Endgerat-Realisierung 
(Hardware) 



MoU-Konzept 



Hersteller 



fig. I : Object and Scope of Specification 



Dynamic 

Route 
Guidance 



AH 



' PC FAX 1 
Applications 
via SCI 




fig. 2: Functional Architecture of the Traffic Telematics Base device 
API: Application Programming Interface 
SCI: Standard Communications Interface 
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2(23 




Interface to Interface to 

GSM Module GPS Module 



ig. 3: Base System with Standard Communicator! Interface (SCI) 
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3|39 

Routing + System Control 




direct access via 

Standard 
Communications 

Interface 



GSM 
Data Transfer 



Communications 
Service Table Acce 




Call Management 
Call A cception SMS-Handling 




indirect AT 
Command Access 



T 



I 



SMS 



Illustration 2.2.1-1: Functional Architecture of the communication subsystem 
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^33 




traffic 
telematics 
terminal 



connectionless 
communication 
(like SMS) 



end-to-ena pf otocoT 

communications 
server 




application 




service 
center 



Illustration 2.2.1-2: Components of Communication between base terminal and 



center 
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terminal equipme nt 




connection 
establishmen 



send data 



receive data 



connection 
termination 




open request 



open confirm 



data request 



data confirm 



data indication 



close request 



close confirm 



service center 



open indication 



open response 



data indication 



data request 



data confirm 



close indication 



Illustration 2.2. 1-3: GSM dialogue sequence of a Bearer Services (connection 
orientated), initiated by the terminal application with an example sequence in the 
service center 
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terminal equipmenl 



applicatiol 



subsystem 
communicatifih 



end-to-enc 
protocol 



connection 
establishment 



send data 



receive data 



connection 
termination 



open request 
*r 



open confirm 



data reques ^ 



data confirrr 



data indication 



close requesft 



close conf irn » 



c 





service center 


end-to-enc 




protocol 





TP-SABM 




TP-UA 



TP-I 



TP-RR 



TP-I 



TP-RR 



TP-DISC 



TP-UA 



open indication 
* 



^tpen respo nse 



data indicaticn 



data requesl 



data confirrr 



close indication 



bv U aTe™ 0 L 2 ." 2 a 1 1 : di !' 0gUe SeqUCnCe ° f BearCr Servic « ««»nnecuon orientated,, iniiiated 

by a terminal application with an example dialogue in the service center 
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8 


7 


6 


5 


4 


3 


2 


1 


0 


) 


1 


1 


1 


1 


1 


0 



Control Field 



Length Indicator 



C/R 



Address 



Information 



Frame Check Sequence 



Frame Check Sequence 



M 



EL 



Begin Rag 
Control Field 
Length Indicator Field 

Data Field 



CRC: 1st octet 
CRC: 2nd octet 



Illustration 2.2. 1 -5: Framework of the TASP4 level 



control field 
bits 


8 


7 


6 


5 


4 


3 


2 


1 


I format 


N(R) 


P 




N(S) 


0 


S format 


N(R) 


P/F 


S 


S 


0 


1 


U format 


U 


U 


U 


P/F 


u 


U 


1 


1. 



Illustration 2.2.1-6: Control Field 
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Format 


Com- 
mands 


Res- 
ponses 


8 


7 


6 


5 


4 


3 


2 


1 


Informa- 
tion 


I 




N(R) 


P 


N(S) 


0 


Super- 
visory 




RR 


N(R) 


P/F 


0 


0 


0 






RNR 


RNR 


NCR) 


P/F 


0 


1 


0 








REJ 


NCR) 


P/F 


1 


0 


0 






C A TJ X/t 




0 


0 


1 


P 


1.1 11 






DM 


0 


0 


0 




1 1 . 1 1 


Unnum- 
bered 


UI 




0 


0 


0 


P 


0 


0 


1 






DISC 




0 


1 


0 


P 


0 


0 


1 








UA 


0 


1- 


] 


F 


0 


0 


1 





Illustration 2.2.1-7: Coding according to the LAPB format 



L 


OR 


M 


EL 
= 1 



Length indicator field 



Illustration 2.2.1-8: Length Indicator Field 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/01110 



3j33 



L 


C/R 


M 


EL-0 


Length indicator field 











Illustration 2.2. 1 -9: Length indicator field for a data field between 0 and 3 1 octet in length 



L 


C/R 


M 


EL - 1 


Length indicator field 










1 st Octet 


L 


EL-0 


2nd Octet 



Illustration 2.2.1-10: Enlarged length indicator field 



ROUTI NG + SYSTEM CONTROL 
j— 



I 



Waypoint 




I 



Waylength 



GPS 
base date 



^ Geometry 



▼ forward 
1 ^ approximated posj tkuis 

GPS Base Data ]_ 



backward 
approximatec 
positions 



Approximation 



GPS positions 



GPS data from 
GPS Receiver 



interface tc/ 
GPS ModuJ 



dujfe 



Illustraiion 2.2.2-1: Functional Archiiekture of the Subsystems Location 
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Illustration 2.2.2-2: Polynomial Forward Approximation 
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ustration 2.2.2-3: Polynomial Backward Approxi 




ustration 2.2.2-4 Fig. I 1: Waypoint Geometry in Case of a Circle 
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width 

of 
inner 
area 



hy 



>ter ;sis 
1 vidt i 



length of inner area 



hysteresis area 



center point 




inner area 



preferred 
directon 



Illustration 2.2.2-5: Waypoint Geometry in Case of a Rectangle 



normal to 
preferred direction 



2 "CENTER 



aperture yr- 

ie ^ 

preferred direction 




Illustration 2.2.2-6: Example of vehicl 



e crossing a circle: 
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normal to 
preferred direction 



2 "CENTER 




Illustration 2.2.2-7: Example of vehicle crossine a recunele: 




base 
functions I/O 



application 1 



application n 



Illustration 2.2.4- 1: bock switching illustration of the subsystem input/output with interpreter 
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Subsystem I/O 




ustraiion 2.2.4-2: Possible realization of input/output 
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1^33 

ROUTING + SYSTEM CONTROL 



T 

( I/O Enter Data 

T 



"XT 

M/O Display Information ^ 

C3p 



interface to 
Input/Output-Device 



Illustration 2.2.4-3: Functional architecture of the subsystem input/output 
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Time sequence diagram for a GSM communication 

a) a communication initiated by the application in case of a 
connection-oriented or connectionless communication 



application 



Request to open a 
GSM connection: 



Sending data: 



Sending new data within 
the current GSM connection: 



Indication: 

The data of the service 
center are sent to the 
application. 



Request to close the 
GSM connection: 



gsm_open_req 



gsm__open_con 



gsm_data_req 



gsm_data_con 



gsm_data_req 



gsm_data_con 



gsm_data_ind 



gsm_close_req 



gsm_close_con 



Remark: 



GSM base 
function 



Logical channel to the 
application is established. In 
case oi a connection-oriented 
communication a connection 
to the service center is being 
established. 



Data are being sent to the 
service center. The service 
center (either Telematic or 
SMS-Cervice Center) sends 
back a confirmation ol the 
receipt of the data which is 
transferred to the application. 



as before 



Telematic data are sent by 
a service center application 
within the current GSM 
connection: 



Logical channel is closed and 
in case of a connection-oriented 
communication the GSM 
connection to the service 
center as well. 



If the GSM connection is closed by the application before the response data are sent 
by the service center application, the service center may establish a new connection 
to send the response data (see diagram 1b or ic) 

Illustration 3.2.3-1: Time sequence diagram related to the GSM base function GSM dialoc 
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Time sequence diagram for a GSM communication 

b) a communication initiated by the service center in case of 
a connection-oriented communication 




Indication: 

A logical channel and a GSM 
connection is indicated 
to the application. The 
indication is confirmed with 
a response message. 



Indication: 

The data of the service 
center are sent to the 
application. 



Sending response data 
within the current GSM 
connection: 



The termination of the logical 
channel and GSM connection 
is indicated. 



gsrn_open_ind 



gsm_open_res 



gsm_data_Jnd 



gsm_data_req 



gsm_data_con 



gsm_close_ind 



GSM base 
function 



A GSM connection is being 
established by the service 
center. 



Data are sent by the 
service center. The GSM 
base function confirms the 
receipt to the service center. 



Response data are sent 
to the telematic service 
center. The receipt is 
confirmed by the service 
center. 



The logical channel and 
the GSM connection is 
closed. 



Remark: 



After sending the response data the application could request the termination of the 
GSM connection by a "gsm_close_req"-message. The GSM base function would then 
close the GSM connection and confirm it by sending a ,, gsm_close_con"-message. 

Illustration 3.2.3-2: Time sequence diagram. related to the GSM base function GSM diaioc 
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Time sequence diagram for a GSM communication 

c) a communication initiated by the service center in case of 
a connectionless communication 




Indication: 

The receipt of a SMS 
message and the opening 
of a logical channel are 
indicated to the application. 
The receipt of the indication 
is confirmed by a response 
message. 

Indication: 

The data of the service 
center are sent to the 
application 



gsm_ppen_jnd 



gsm__open_res 



gsm_data_Jnd 



gsm_close_ind 



GSM base 
function 



SMS message is sent by 
the service center. 



Immediately after the 
response of the application 
the data of the service center 
are sent. 



time duration "t" 



The logical channnel is 
open for time duration '1" to 
receive more SMS data for the 
related application. If no SMS 
message is received, the 
channel is closed; which is 
indicated to the application. 



Illustration 3.2.3-3: 



Time sequence diagram related to the GSM base function GSM dialog 
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Time sequence diagram for a GSM communication 

d) an error occurs while opening the GSM connection 




Request to open a 
GSM connection: 



Status: 

There is no GSM 
connection to the 
service center. 



gsm_open_req 



gsm_status__ind 



GSM base 
function 



GSM base function tries to 
open a GSM connection 
to the service center. 



Error: 

It is not possible to open 
a GSM connection to 
the service center. 



Situation: 

tTTo e ^ e Jf, n K° ° P< T G ? M co " n< r ction t0 th e service center and no logical channel between 
the GSM base function and the application. If the application still wants to open a GSM 

SragramTa) 0 daiBt '' A haS t0 Start aQain with a "9 sm -OPen.req"-message (see 

Illustration 3.2,3-4: Time sequence diagram related to the GSM base function GSM dialog 
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Time sequence diagram for a GSM communication 

e) an error occurs or connection is cut while transferring data 



application 



Request to open a 
GSM connection: 



1 



Sending data: 



Status: 

Data are not completely 
sent to the service center. 

At this point the application 
decides wether it repeats the 
transfer or closes the 
connection. 



gsm_open_req 



gsm_open_con 



gsm_data_req 



gsm_status_ind 



1 



1 



GSM base 
function 



Logical channel to the 
application is established. In 
case of a connection-oriented 
communication a connection 
to the service center is being 
opened. 



GSM base function tries to 
sent data to the service center. 

Error: 

An error occurs while 
transferring data. Data are 
not completely received by 
the service center, but 
GSM connection is still 
open.Retrail mechanisms 
ofTASP4 failed. 



1. Possibility: 
new trial 



Request to close the 
GSM connection: 



2. Possibility: 

Connection is closed. 



Same data set could be sent 
later (see diagram a) 



gsm_data_req 



gsm_data_con 



gsm_close_req 



gsm_close_con 



1 



Data are being sent to the 
service center. The service 
center sends back a confir- 
mation of the complete 
receipt of the data. 



Logical channel is closed and 
in case of a connection-oriented 
communication the GSM 
connection to the service 
center as well. 



gsm_close_req 



gsm_close_con 



Logical channel is closed and 
in case of a connection-oriented 
communication the GSM 
connection to the service 
center as well. 



Illustration 3.2.3-5: Time sequence diagram related to the GSM base function GSM dialog 
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Time sequence diagram for a GSM communication 

f) connection is cut while transferring data 




Request to open a 
GSM connection: 



Sending data: 



gsm__open_req 



gsm_open_con 



gsm_data_req 



Status: 

A serious error occured. Data 
are not completely 
sent to the service center 
and GSM connection is cut. 

Now the application requests 
the termination of the logical 
channel: 



At this point the application 
decides wether it opens a new 
GSM connection to repeat the 
transfer e. g. using a different 
GSM service or not. 



gsm_status_ind 



gsm_close_req 



gsm__close_con 



GSM base 
function 



Logical channel to the 
application is established, in 
case of a connection-oriented 
communication a connection 
to the service center is being 
opened. 



GSM base function tries to 
send data to the service center. 



Error: 

Connection is cut while 
transferring data. Call 
management retries 
connection several times. 
Data are not completely 
received by the service 
center. 



Logical channel to the 
application is closed. 



Illustration 3.2.3-6: Time sequence diagram related 10 the GSM base function GSM dialog 
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2*/ 33 

Time sequence diagram: GPS base functions 
"base data" and "approximation" 




Request: 

The current GPS data set is 
requested and the following 
every 5 seconds. 



Request: 

The transfer of GPS data 
sets is requested to be 
stopped. 



gps_data_start_req 



gps_data_ind 



gps__datajnd 



gps_data_ind 



gps_data_ind 



gps_data_jnd 



Request: 

The transler of the backward 
approximated GPS data 


gps_approx_data_ 


backward. 


_req 


is requested. 










9£s_approx_data_ 


backward. 


jnd 




^ gps_data. 


jnd 





gps_data_stop_req 



GPS base functions 



1 



Indication: 

the current GPS data set 
(valid) 



Indication: (5 sec later) 
the current GPS data set 
(valid) 



Indication: (5 sec later) 
the current GPS data set 
(forward approximated) 



Indication: (5 sec later) 
the current GPS data set 
(forward approximated) 



Indication: 

the current GPS data set 
(valid) 



Indication: 

the backward approximated 
positions of the gap 



Indication: 

the current GPS data set 
(valid) 



The transfer of .GPS data sets 
is stopped. 



Illustration 3.2.4-1: Time sequence diagram related to the GPS base functions GPS base data and 

approximation 
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Time sequence diagram: GPS base function 

"waylength ff 




Request: 

The counter is requested to 
be resetted on a fixed 
waylength that should be 
covered (-2000m) and to 
be started incrementing 
(indications at -200m, 
-100m and -50m) 



Request: 

Current counter value is 
requested to be sent. 



gps_waylength_start_req 



gps_waylength_req 



gps_waylength_jnd 



gps_waylength__ind 



gps_waylength_ind 



gps_waylengthjnd 



gps__waylengthjnd 



GPS base function 
waylength 



Action: 

The counter is resetted to 
-2000m and started to 
increment. 



Indication: 

Current counter value 

is -1234 m. 



Indication: 

Current counter value 

is -199 m. 



Indication: 

Current counter value 

is -95 m. 

Indication: 

Current counter value 
is -48 m. 

Indication: 
Current counter value 
is 4 m, the whole 
waylength is covered. 



The waylength counter is stopped 
automatically by the base function. 



Illustration 3.2.4-2: Time sequence diagram related to the GPS base function wavleneth 
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Time sequence diagram: GPS base function 

"waypoint" 




Request: 

The base function is 
initialized by sending the 
waypoint data. 



Request: 

The waypoint calculation is 
requested to be stopped 



gps_waypoint_start_req 



gps_waypoint_status_ind 



gps_way po i nt_statu s_i nd 



gps_waypoint_status_ind 



gps_waypoint_stop_req 



GPS base function 
waypoint 



Action: 

With the waypoint data the 
waypoint calculation is started. 



Indication: 

Status: "IN" 

(Car is inside the inner area 
of the waypoint,) 



Indication: 

Status: "CENTER" 

(Car has crossed the normal to 

the preferred direction throughf 

the center. Heading is inside the 

aperture cone of the preferred 

direction.) 



Indication: 

Status: "OUT" 

(Car has left the hysteresis 

area of the waypoint heading 

outside.) 



The waypoint calculation is 
stopped. 



Illustration 3.2.4-3: Time sequence diagram related to the GPS base function waypoint 
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Time sequence diagram for a CIM communication 




Request to open a 
chipcard connection: 



Sending data and status: 



Sending data within 
an error message: 



Requesting the chipcard 
status: 



Sending new data 



Request to close the 
chipcard connection: 



cim_open_application_req 



cim_open_application_con 



cim_send__data_req 



cim__send_data_res 



cim__send_data_req 



cim_status ind 



cim_status__req 



cim_status_ind 



cim_send_data_req 



cirri send data res 




Logical channel to the 
application is established. 
A connection to the 
chipcard is being opened. 



cim_close_applicatiorweq 



a Cim_close_application_con 



Data are being sent to the CIM. 
Alter transferring data to the 
chipcard the response data ol the 
chipcard is sent to the application. 



The chipcard has been 
pulled out. 

Status of- CIM : No chipcard 



The chipcard is pulled in. 
Status of CIM: Chipcard o. k. 



"Normal processing" 



Logical channel is closed. 



Illustration 3.2.5-1; Time sequence diagram related to the Subsystem Access Control 
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<t__queue> 




Illusiraiion 3.2.6-1: Phase diagram related to the I/O base function display information 
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display accessable, no interruption 

Time-sequence diagram for information display 



application 



] 



status: 

display information in 
process 



status: 

display information done 



io_display_information req 
— - ^HH 



io_display_information con 



^_displayjnformation_ack 



I/O base 
function 



status: 

display: accessable 



t dur 



action: 

display information for time 
period t_dur 
status: 
display: busy 



status: 

display: accessable 



Illustration 3.2.6-2: Time sequence diagram related to the I/O base function display information 
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display access delayed, no interruption 

Time-sequence diagram for information display 



application 



status: 

display request in queue 



io_displayJnformation_req 



io_displayJnformation_con 



status: 

display information done 



io_displayjnformation_ack 



I/O base 
function 



status: 

display: busy 



status: 
display: busy 
action: 

request: into queue 



status: 

display: accessable 
action: 

when t < t_queue 



action: 

display information for 
*_uU r time period t_dur 
status: 
display: busy 



status: 

display: accessable 



Illustration 3.2.6-3: Time sequence diagram related to the I/O base function display informal 



ion 
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display access delayed and rejected 

Time-sequence diagram for information display 



application 



status: 

display request in queue 



io_display_information_req 



io_display_information_eon 



I/O base 
function 



status: 

display: busy 



status: 

display: busy 
request: into queue 



t 



status: 

display information rejected; 
t_queue exceeded 



display Jnformatiorwej 



when t >« t__queue 
action: 

display information rejected 
and deleted from queue 
status: 
display: busy 



display access rejected 

Time-sequence diagram for information display 



application 



1 



status: 

display information rejected: 

a. access not allowed; 

b. display not operational 



io_display_information_req 



io_display_information_rej 



I/O base 
function 



status: 

a. display: free or busy 

b. display not operational 



status: 

a. request: not allowed for 
this display 

b. display not operational 



Illustracion 3.2.6-4: Time sequence diagram related to the I/O base function display information 
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display access with interruption 

Time-sequence diagram for information display 



application (1) 
low priority 



] 



status: 

information (1) displayed 



application (2) 
high priority 



status: 

display information (1) 
interrupted 

information (2) displayed 



status: 

display information (2) 
done 

information (1) displayed 



status: 

display information (1) 
done 



io__display_information_req (1) 



io_displayJnformation_con (1) 



I/O base 
function 



io_display_information_req (2) 



status: 
display: free 



status: 

display: busy (1) 
action: 

display info for time period t_dur (1) 



io displayJnfo rmation_int (1) 
io displayjnfo rmation_con (2)| 

io_displayJnformation_ack (2) 
io_displayJnformation_con (1) 



during t_dur(1) 

new display information request 
(2) with a higher priority than 
the actual display information 
request (1) 



action: 

Display information (1) is 
interrupted and put in queue; 
owner application is to informed 
about interrupt. 

display information (2) for time 
period t_dur (2) 



T Ldur(2) 



iodisplayjnfonmation_ack (1 ) 



status: 

display information (2) is finished 

display reaccessable for 

application(l) 

when t(1) < t_queue (1) 

action: 

Display information request (1) is 
taken from queue and displayed 
for t_dur (1) 
t_dur (1) 



Illustration 3.2.6-5: Time sequence diagram related to the VO base fun 



ction display information 
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attach/detach input device 

Time-sequence diagram for enter data 



application 



status: 

input device attached 



status: 

input device not attached 



attach 



io_input_device_req 



io_input_device_ack 



application 



io_input__device_rej 



detach 



id_input_device_req 



status: 

input device detached 



io_input__device_ack 



I/O base 
function 



if 

status input device = free 
action: 

attach input device to 
application 

status input device = busy 

else 
action: 

reject input device request 



I/O base 
function 



status input device = busy: 
action: 

detach input device to 
application 

status input device = free 



Illustration 3.2.6-6: Time sequence diagram related to the I/O base function enter data 
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ENTER DATA 

Time-sequence diagram for enter data 



status: 

input device attached 



status: 

input device detached 



attach 




ioJnput_deyice__req 



ioJnput_device__ack 



io_enter_data_req 



io_enter_data__co n 



I/O base 
function 



io_enter_data_res 



io_enter_data__rej 



io_enter_data ind 



ioJnput__device_req 



ioJnput_device_ack 



action: 

attach input device 



action: 

request for input data 
start watchdog 



action: 

send input data to 

application 

or 

reject input data (cancel) 



if an event key is 
pushed: 

send indication to 
application 



action: 

detach input device 



Illustration 3.2.6-7: Time sequence diagram related to the I/O base 



function enter data 
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33)39 



indirect 
without 



acce; s 
protoi ol 



Standard Communication In 




indirect access with 
security protocol 



Routing + System Co 



external 
application 



or 



devices 




direct access 



Illustration 4.2-1: Standard Communications Interface (SCI) 
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Cause 


Cause 




num 






1 


Unassigned (unallocated) number 


. 3 


No route to destination 


6 


Channel unacceptable 


8 


Operator determined barring 




16 


Normal call clearing — 




17 


User busy 1 


18 


No user responding I 


19 


User alerting, no answer 


21 


Call rejected j 


22 


Number changed 


26 


Non selected user clearing 




27 


Destination out of order "~ 




28 


Invalid number format (incomplete number) 


29 


Facility rejected I 


30 


Response to STATUS ENQUIRY 


31 


Normal, unspecified J 


34 


No circuit/channel available 


38 


Network out of order J 


41 


Temporary failure 


42 


twitching equipment congestion 


43 


Access information discarded 


44 


requested circuit/channel not available 




47 


Resources unavailable, unspecified 




49 


Quality of service unavailable 


50 


Requested facility not subscribed 


55 


Incoming calls barred within the CUG 




57 


Bearer capability not authorized 




58 


Bearer capability not presently available 




63 


Service or option not available, unspecified 




65 J 


Nearer service not implemented 




68 > 


\CM equal to or greater than ACMmax 




69 I Requested facility not implemented 





e 1 - 1 . continued on next pace 
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3r/?g 



70 


Onlv restricted Hi 01m I infr%r-m ^ _ 

^riuj iwjuiv,icu uiaiui information nearer capability 

is available 


79 


Service or ODtion not imnlpmpntpw im^r^^f.^^ 
iivji nit jjicincnicci. unspecineo 


81 


Invalid transaction identifier waino 

^ «t*»4ouw.injji JUwJllIllCJ Value 


87 


User not memhpr of PT in 


88 


lnSUDDOrteH dpQtinntiriT* 
• iidu^puii^u UwaulldUUll 


91 


Invalid transit network selection 


95 


•j&ijiaiiiicdiiy incorrect message 


96 


invdiiu rn<inuaiory inrormation 


97 


ivic2>2»a£e iype non-existent or not implemented 


98 


jviessage type not supported with protocol state 


99 


iniuimaiion element non-existent or not 
implemented 


100 


Conditional IE error 


101 


Message not supported with protocol state 


102 


Recovery on timer expiry 


111 


Protocol error, unspecified 


127 


Interworking, unspecified 



Table 5.1-1 
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cuse 
num + 
128 


cause 


128 


phone failure 


129 


no connection to phone 


130 


phone-adaptor link reserved 


131 


operation not allowed 


132 


operation not supported 


133 


PH-SIM PIN required 


138 


SIM not inserted 


139 


SIM PIN required 


140 


SIM PUK required 


141 


SIM failure 


142 


SIM busy 


143 


SIM wrong 


144 


incorrect Dasswnrd 


148 


memory full 


149 


invalid index 


150 


not found 


151 


memory . failure 


152 


text strin-j? too Inn a 


153 


invalid characters in text string 


154 


dial string too long 


155 


invalid characters in dial string 


158 


no network service 


159 


network timeout 


228 


unknown 



Table 5.1-2 



SUBSTITUTE SHEET (RULE 26) 



WO 97/34431 



PCT/EP96/O1110 







cuse 


cause 


num 




500 


Connection temporarily not available 


501 


Connection fivailnHI«> 


600 


□RSe function Hnpcn " t onomai- 
i^ii^liuii uucin i answer 


60) 


base function not nn^ra r i 1 1 


602 


base function n rvr arrpcciKla / _ _ _ , j~ , 

uaac ,U " LUUI1 ntK accessioie (no access right for the 
reouestine anDlicAtion^ 


610 


base function hncv/ ULnrK r\- . u 

isuov* 1 "nv^tujii uu.sy wnn priority ,»(J 


61 1 


n3Se function hnc\* n/tr-K . i -» 

iunLiiun uusy wiui. priority „I 


612 


base function Kikv vLMt-h ^ ... « . . 
>«m»uuii uudy wiiii priority 


613 


base function busy with priority ,.3" 


614 


base flinrtinn Knew u/itki n» n _ ^ . . 

ua ' 3 *- *i-h»uihjii ou^y wim priority .4 


630 


oujjd jidiiic. source un Known 


631 


iupenrame. destination unknown 


632 


superframe: transaction number unknown or out of 
range 


633 


SUnerirann^' nrirtrirw i ml'nrti, •«-. ^ _ _ . _c 

oupuuamt. pnuruy unknown or out of ranee 


635 


SUDCfframe* ^onrr*** m i c c m <i 
uw^Miimnk,, OUUlwC IlllSoing 


636 


SUDerTranri^* fipcrtnatinti miroinn 
du|/v.iiiaiii&, ucALiiidiion missinc 


637 


superframe: transaction number missing 


638 


aupuudiiic. pnoniy missins 


640 


ud&c lunciion. message id unknown 


641 


ua^c junction, message data element missms 


642 


base function* m^ccnop Ho»-» i ,. . . . 

u«c luutuun. message aata element wrong or out or 

range 


643 


base lUnCtlOn* \\srr\ncr rliol in» _ . i_ / r- j. , ■ 

uaac .""tuon. wrong dialing number (fix dialing) 


700 


GSM service not available 


701 


call bearing (Rufnummer gesperm 


702 

J 


keine Berechtigung fur den jeweilicen 
Datendienst/Fax 


703 1 


"vetz: gassenbesetzt fUberlast) 
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